On Windows a process can't delete its own current direcotry, that's why the test
needs to return to the original direcotry before removing newdir.
llvm-svn: 313113
The FXSAVE member `ftw` (FPU Tag Word) was given the wrong size (8-bit)
instead of the correct width (16-bit) as per the x87 Programmer's
Manual. Adjust this to ensure that we print out the complete value for
the register.
llvm-svn: 311579
This is the FreeBSD equivalent of r238549.
This serves 2 purposes:
* LLDB should handle inferior process signals SIGSEGV/SIGILL/SIGBUS/
SIGFPE the way it is suppose to be handled. Prior to this fix these
signals will neither create a coredump, nor exit from the debugger
or work for signal handling scenario.
* eInvalidCrashReason need not report "unknown crash reason" if we have
a valid si_signo
llvm.org/pr23699
Patch by Karnajit Wangkhem
Differential Revision: https://reviews.llvm.org/D35223
llvm-svn: 310591
Summary:
The available platform list was previously only accessible via the
`platform list` command, this patch makes it possible to access that
list via the SBDebugger API. The active platform list has likewise
been exposed via the SBDebugger API.
Differential Revision: https://reviews.llvm.org/D35760
llvm-svn: 310452
You can get a breakpoint to auto-continue by adding "continue"
as a command, but that has the disadvantage that if you hit two
breakpoints simultaneously, the continue will force the process
to continue, and maybe even forstalling the commands on the other.
The auto-continue flag means the breakpoints can negotiate about
whether to stop.
Writing tests, I wanted to supply some commands when I made the
breakpoints, so I also added that ability.
llvm-svn: 309969
When an option was set at on a location, I was just copying the whole option set
to the location, and letting it shadow the breakpoint options. That was wrong since
it meant changes to unrelated options on the breakpoint would no longer take on this
location. I added a mask of set options and use that for option propagation.
I also added a "location" property to breakpoints, and added SBBreakpointLocation.{G,S}etCommandLineCommands
since I wanted to use them to write some more test cases.
<rdar://problem/24397798>
llvm-svn: 309772
Summary:
SBBreakpointLocation exposed the ignore count, but didn't expose
the hit count. Both values were exposed by SBBreakpoint and
SBWatchpoint, so this makes things a bit more consistent.
Reviewers: lldb-commits
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D31283
llvm-svn: 308480
In NativeProcessLinux::MonitorSIGTRAP we were asserting that the si_code
value is one of the codes we know about. However, that list was very
incomplete -- for example, we were not handling SI_TKILL/SI_USER,
generated by raise(SIGTRAP). A cursory examination show there are at
least a dozen codes like these that an app can generate, and more can be
added at any point.
So, instead of trying to play catchup, I change the default behavior to
treat an unknown si_code like an ordinary signal. The only reason we
needed to inspect si_code in the first place is because
watchpoint/breakpoints are notified as SIGTRAP, but we already know
about those, and us starting to use a new debug event is far less likely
than somebody introducing a new non-debug event.
I add a test case to TestRaise to verify we are handling raise(SIGTRAP)
in an application properly.
llvm-svn: 307644
Starting with android ndk r15, clang much more tests are affected by the
-mstackrealign bugl (now nearly all functions are affected, and not just
the ones requiring 16-byte alignment). Due to their numbers, Xfailing
all of them is not a viable option, so we will just have to declare this
configuration unsupported, and wait until ndk ships a clang version that
has this bug fixed.
llvm-svn: 307252
This adds a simple testcase for MainThreadCheckerRuntime. The tool (Main Thread Checker) is only available on Darwin, so the test also detects the presence of libMainThreadChecker.dylib and is skipped if the tool is not available.
llvm-svn: 307170
All android builds systems have switched to -mstackrealign for building
x86 binaries, so follow their cue with our mini build system.
This presently breaks just one test (TestReturnValue), and this is due
to a compiler bug, which has already been fixed in clang, but it hasn't
made it yet into the official NDK compiler. While I'm touching that
test, I also remove an android-specific XFAIL, which is not relevant
anymore.
llvm-svn: 306683
This patch introduces a new thread backtrace command "unique".
The command is based off of "thread backtrace all" but will instead
find all threads which share matching call stacks and de-duplicate
their output, listing call stack and all the threads which share it.
This is especially useful for apps which use thread/task pools
sitting around waiting for work and cause excessive duplicate output.
I needed this behavior recently when debugging a core with 700+ threads.
Differential Revision: https://reviews.llvm.org/D33426
Reviewers: clayborg, jingham
Patch by Brian Gianforcaro <b.gianfo@gmail.com>
llvm-svn: 305197
I was over-eager to unable this test in r304976. It still fails in this
combination, at there does not seem to be anything we can do about it,
as the generated code does not preserve the link register.
llvm-svn: 305062
Summary:
When a call instruction is the last instruction in a function, the
backtrace PC will point past the end of the function. We already had
special code to handle that, but we did not handle the case where the PC
ends up outside of the bounds of the module containing the function,
which is a situation that occured in TestNoreturnUnwind on android for
some arch/compiler combinations.
I fix this by adding an argument to Address resolution code which states
that we are ok with addresses pointing to the end of a module/section to
resolve to that module/section.
I create a reproducible test case for this situation by hand-crafting an
executable which has a noreturn function at the end of a module.
Reviewers: jasonmolenda, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D32022
llvm-svn: 304976
as described in pr33042, we cannot reliably retrieve the return value on
arm64 in cases it is returned via x8 pointer. I tried to do this as
surgically as possible and disabled it only on targets I know to be
affected, as the code is still useful, even though it can only work on
best-effort basis.
llvm-svn: 303076
Summary:
Arm64 Procedure Call Standard specifies than only vectors up to 16 bytes
are stored in v0 (which makes sense, as that's the size of the
register). 32-byte vector types are passed as regular structs via x8
pointer. Treat them as such.
This fixes TestReturnValue for arm64-clang. I also split the test case
into two so I can avoid the if(gcc) line, and annotate each test
instead. (It seems the vector type tests fail with gcc only when
targetting x86 arches).
Reviewers: tberghammer, eugene
Subscribers: aemerson, omjavaid, rengolin, srhines, lldb-commits
Differential Revision: https://reviews.llvm.org/D32813
llvm-svn: 302220
Summary:
The existing cpp-level checks using PR_MPX_ENABLE_MANAGEMENT aren't sufficient,
as this isn't defined for linux kernel versions below 3.19.
Reviewers: valentinagiusti, zturner, labath
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D32719
llvm-svn: 302027
Summary:
MergeFrom was updating the architecture if the target triple did not
have it set. However, it was leaving the core field as invalid. This
resulted in assertion failures in core file tests as a missing core
meant we were unable to compute the address byte size properly.
Add a unit test for the new behaviour.
Reviewers: jingham, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D32221
llvm-svn: 300836
I thought my previous commit got the last ones but somehow I missed
these. This also resurrects TestDataFormatterLibcxxSet, which got
commented out in r263859 as a part of some seemingly unrelated change.
llvm-svn: 300833
r285226 dropped the code that did these checks. I am pretty
sure that was inadvertent, so I added that back in and added
a test for it.
<rdar://problem/31661252>
llvm-svn: 300564
Summary:
The iteration list through the available data formatters was undefined,
which meant that the vector<bool> formatter kicked in only in cases
where it happened to be queried before the general vector formatter. To
fix this, I merge the two data formatter entries into one, and select
which implementation to use in the factory function.
Reviewers: jasonmolenda, tberghammer, EricWF
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D31880
llvm-svn: 300047
gcc emits DW_LANG_C89 even if we specify -std=c99 during compilation.
Since this isn't an lldb bug, but just the way the compiler happens to
be implemented, I teach the test to expect this situation correctly.
llvm-svn: 300046
I have put them all in their own category, and made that category disabled by default.
Differential revision: https://reviews.llvm.org/D31718
llvm-svn: 299587
look showed that the target's arch has no core / byte order and so when
AuxVector::AuxVector calls into a dataextractor and sets the byte size to 0,
it asserts. e.g.
m_arch = {
m_triple = (Data = "x86_64--linux", Arch = x86_64, SubArch = NoSubArch, Vendor = UnknownVendor, OS = Linux, Environment = UnknownEnvironment, ObjectFormat = ELF)
m_core = kCore_invalid
m_byte_order = eByteOrderInvalid
m_flags = 0x00000000
m_distribution_id = <no value available>
}
<rdar://problem/31380097>
llvm-svn: 299408
Summary:
After this change a sythetic child provider can generate a special child
named "$$dereference$$" what if present is used when "operator*" or
"operator->" used on a ValueObject. The goal of the change is to make
expressions like "up->foo" work inside the "frame variable" command.
Reviewers: labath, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D31368
llvm-svn: 299251
