Most of the watchpoint tests are organized into subtrees, so we can use the
file-based .categories approach to annotate them. The exception are the
concurrent_events tests, which needed to be annotated on a per-test basis.
The motivation behind this is to provide an easy way to disable watchpoint
tests on systems where the watchpoint functionality is not present/unreliable.
llvm-svn: 317004
Summary:
This adds a data formatter for the implementation of forward_list in
libc++. I've refactored the existing std::list data formatter a bit to
enable more sharing of code (mainly the loop detection stuff).
Reviewers: jingham, EricWF
Subscribers: srhines, eugene, lldb-commits
Differential Revision: https://reviews.llvm.org/D35556
llvm-svn: 316992
The test was asserting that we can only find one frame in the minidump.
Now that we have the default unwind plan from the ABI plugin, we are
able to find 5 more frames using the frame pointer chaining. Correct the
expectation in the test.
llvm-svn: 316688
The core of this change is the new CommandInterpreter::m_command_state,
which models the state transitions for interactive commands, including
an "interrupted" state transition.
In general, command interruption requires cooperation from the code
executing the command, which needs to poll for interruption requests
through CommandInterpreter::WasInterrupted().
CommandInterpreter::PrintCommandOutput() implements an optionally
interruptible printing of the command output, which for large outputs
was likely the longest blocking part.
(ex. target modules dump symtab on a complex binary could take 10+ minutes)
Differential Revision: https://reviews.llvm.org/D37923
llvm-svn: 315037
running watchos. These tests cannot run on normal customer devices,
but I hope to some day have a public facing bot running against a
device.
llvm-svn: 314355
in TestDataFormatterSkipSummary.py - I'm building this test
with the default c++ library.
Skip TestMTCSimple.py when running for i386.
llvm-svn: 314155
Normal customer devices won't be able to run these tests, we're hoping to get
a public facing bot set up at some point. Both devices pass the testsuite without
any errors or failures.
I have seen some instability with the armv7 test runs, I may submit additional patches
to address this. arm64 looks good.
I'll be watching the bots for the rest of today; if any problems are introduced by
this patch I'll revert it - if anyone sees a problem with their bot that I don't
see, please do the same. I know it's a rather large patch.
One change I had to make specifically for iOS devices was that debugserver can't
create files. There were several tests that launch the inferior process redirecting
its output to a file, then they retrieve the file. They were not trying to test
file redirection in these tests, so I rewrote those to write their output to a file
directly.
llvm-svn: 314132
Normal customer devices won't be able to run these devices, we're hoping to get
a public facing bot set up at some point. Both devices pass the testsuite without
any errors or failures.
I have seen some instability with the armv7 test runs, I may submit additional patches
to address this. arm64 looks good.
I'll be watching the bots for the rest of today; if any problems are introduced by
this patch I'll revert it - if anyone sees a problem with their bot that I don't
see, please do the same. I know it's a rather large patch.
One change I had to make specifically for iOS devices was that debugserver can't
create files. There were several tests that launch the inferior process redirecting
its output to a file, then they retrieve the file. They were not trying to test
file redirection in these tests, so I rewrote those to write their output to a file
directly.
llvm-svn: 314038
Normal customer devices won't be able to run these devices, we're hoping to get
a public facing bot set up at some point.
There will be some smaller follow-on patches. The changes to tools/lldb-server are
verbose and I'm not thrilled with having to skip all of these tests manually.
There are a few places where I'm making the assumption that "armv7", "armv7k", "arm64"
means it's an ios device, and I need to review & clean these up with an OS check
as well. (Android will show up as "arm" and "aarch64" so by pure luck they shouldn't
cause problems, but it's not an assumption I want to rely on).
I'll be watching the bots for the rest of today; if any problems are introduced by
this patch I'll revert it - if anyone sees a problem with their bot that I don't
see, please do the same. I know it's a rather large patch.
One change I had to make specifically for iOS devices was that debugserver can't
create files. There were several tests that launch the inferior process redirecting
its output to a file, then they retrieve the file. They were not trying to test
file redirection in these tests, so I rewrote those to write their output to a file
directly.
llvm-svn: 313932
The main change is to avoid setting the process state as running when
debugging core/minidumps (details in the bug). Also included a few small,
related fixes around how the errors propagate in this case.
Fixed the FreeBSD/Windows break: the intention was to keep
Process::WillResume() and Process::DoResume() "in-sync", but this had the
unfortunate consequence of breaking Process sub-classes which don't override
WillResume().
The safer approach is to keep Process::WillResume() untouched and only
override it in the minidump and core implementations.
patch by lemo
Bug: https://bugs.llvm.org/show_bug.cgi?id=34532
Differential Revision: https://reviews.llvm.org/D37651
llvm-svn: 313655
When introduced, breakpoint names were just tags that you could
apply to breakpoints that would allow you to refer to a breakpoint
when you couldn't capture the ID, or to refer to a collection of
breakpoints.
This change makes the names independent holders of breakpoint options
that you can then apply to breakpoints when you add the name to the
breakpoint. It adds the "breakpoint name configure" command to set
up or reconfigure breakpoint names. There is also full support for
then in the SB API, including a new SBBreakpointName class.
The connection between the name and the breakpoints
sharing the name remains live, so if you reconfigure the name, all the
breakpoint options all change as well. This allows a quick way
to share complex breakpoint behavior among a bunch of breakpoints, and
a convenient way to iterate on the set.
You can also create a name from a breakpoint, allowing a quick way
to copy options from one breakpoint to another.
I also added the ability to make hidden and delete/disable protected
names. When applied to a breakpoint, you will only be able to list,
delete or disable that breakpoint if you refer to it explicitly by ID.
This feature will allow GUI's that need to use breakpoints for their
own purposes to keep their breakpoints from getting accidentally
disabled or deleted.
<rdar://problem/22094452>
llvm-svn: 313292
The auto-continue test was using the new (better) name
for providing commands (-C) but I haven't checked in that change
yet. Put the test back to the old way for now.
llvm-svn: 313221
The main change is to avoid setting the process state as running when
debugging core/minidumps (details in the bug).
Also included a few small, related fixes around how the errors propagate in
this case.
patch by lemo
Bug: https://bugs.llvm.org/show_bug.cgi?id=34532
Differential Revision: https://reviews.llvm.org/D37651
llvm-svn: 313210
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
Summary:
Displaying the object pointed by the unique_ptr can cause an infinite
recursion when we have a pointer loop so this change stops that
behavior. Additionally it makes the unique_ptr act more like a class
containing a pointer (what is the underlying truth) instead of some
"magic" class.
Reviewers: labath, jingham
Differential Revision: https://reviews.llvm.org/D31366
llvm-svn: 299249
Summary:
This aims to replace the different decorators we've had on each libc++
test with a single solution. Each libc++ will be assigned to the
"libc++" category and a single central piece of code will decide whether
we are actually able to run libc++ test in the given configuration by
enabling or disabling the category (while giving the user the
opportunity to override this).
I started this effort because I wanted to get libc++ tests running on
android, and none of the existing decorators worked for this use case:
- skipIfGcc - incorrect, we can build libc++ executables on android
with gcc (in fact, after this, we can now do it on linux as well)
- lldbutil.skip_if_library_missing - this checks whether libc++.so is
loaded in the proces, which fails in case of a statically linked
libc++ (this makes copying executables to the remote target easier to
manage).
To make this work I needed to split out the pseudo_barrier code from the
force-included file, as libc++'s atomic does not play well with gcc on
linux, and this made every test fail, even though we need the code only
in the threading tests.
So far, I am only annotating one of the tests with this category. If
this does not break anything, I'll proceed to update the rest.
Reviewers: jingham, zturner, EricWF
Subscribers: srhines, lldb-commits
Differential Revision: https://reviews.llvm.org/D30984
llvm-svn: 299028
This was added to workaround a limitation in LLVM's implementation
of getting the current user's home directory, since it would
only look at the value of $HOME, but we did not want to rely
on that being set so we would also look in the password database.
Adding the ability to look in the password database to LLVM was
a straightforward patch that was submitted in r298513, so since
that is done this test is no longer needed.
llvm-svn: 298519
Only do this when we are debugging an executable, since we
don't have a good way to trace from an ObjectFile back to its
containing executable. Detecting pre-run libs before running
is "best effort" in lldb, but this one is pretty easy.
llvm-svn: 298290
It seems that on darwin we are not able to resolve breakpoints in the
test shared library until the process has started. That seems
unfortunate, but it is not the purpose of this test, so work around that
by starting the process before doing the rest of our checks.
llvm-svn: 297830
Summary:
This fixes the case where a user tries to set a breakpoint on a source
line outside of any function (e.g. because that code is #ifdefed out, or
the compiler did not emit code for the function, etc.) and we would
silently move the breakpoint to the next function.
Now we check whether the line range of the resolved symbol context
function matches the original line number. We reject any breakpoint
locations that appear to move the breakpoint into a new function. This
filtering only happens if we have full debug info available (e.g. in
case of -gline-tables-only compilation, we still set the breakpoint on
the nearest source line).
Reviewers: jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D30817
llvm-svn: 297817
Summary:
There is nothing we can do with the breakpoint once the associated
target becomes deleted. This will make sure we don't hold on to more
resources than we need in this case. In particular, this fixes the case
TestStepOverBreakpoint on windows, where a lingering SBBreakpoint object
causes us to nor unmap the executable file from memory.
Reviewers: clayborg, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D30249
llvm-svn: 296328
Summary:
This also removes magic rename code, which caused the channel to be
called "linux" when built on a linux machine, and "freebsd" when built
on a freebsd one, which seems unnecessary - registering a new channel is
sufficiently simple now that if we wish to log something extremely
os-specific, we can just create a new channel. None of the current
categories seem very specific to one OS or another.
Reviewers: emaste, krytarowski
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D30250
llvm-svn: 295954
r290874 enabled the s390x test, which caused the rest of the tests to start
misbehaving. This is because this test switches the selected platform and the
change persists.
This fixes it by explicitly resetting the platform in a similar way to the gcore
tests do. Potentially we should consider re-setting the platform globally
between each test run to better protect tests from each other.
llvm-svn: 290890
Summary:
This patch changes and simplifies the way notes are read from Linux Elf cores.
The current implementation copies the bytes from the notes directly over the lldb structure for 64 bit cores and reads field by field for 32 bit cores. Reading the bytes directly only works if the endianess of the core dump and the platform that lldb are running on matches. The case statements for s390x and x86_64 would would only work on big endian systems and little endian systems respectively. That meant that x86_64 generally worked but s390x didn't unless you were on s390x or another big endian platform.
This patch just reads field by field on all platform and updates the field by field version to allow for those fields which are word size instead of fixed size. It should also slightly simplify adding support for a new Linux platform.
This patch also re-enables the s390x test case in TestLinuxCore.py on all non-s390x platforms as it now passes.
Reviewers: uweigand, clayborg
Differential Revision: https://reviews.llvm.org/D27571
llvm-svn: 290874
Fixed by additional completed plans detection, and applying them on breakpoint condition fail.
Thread::GetStopInfo reworked. New test added.
Review https://reviews.llvm.org/D26497
Many thanks to Jim
llvm-svn: 290168
This test passes consistently on linux, so I am removing the overall XFAIL. If it
fails on your configuration, please put a targeted xfail instead (i'll add them
my self if I get any breakage emails).
llvm-svn: 287881
Summary:
This patch changes the way ProcessElfCore.cpp handles signal information.
The patch changes ProcessElfCore.cpp to use the signal from si_signo in SIGINFO notes in preference to the value of cursig in PRSTATUS notes. The value from SIGINFO seems to be more thread specific. The value from PRSTATUS is usually the same for all threads even if only one thread received a signal.
If it cannot find any SIGINFO blocks it reverts to the old behaviour and uses the value from cursig in PRSTATUS. If after that no thread appears to have been stopped it forces the status of the first thread to be SIGSTOP to prevent lldb hanging waiting for any thread from the core file to change state.
The order is:
- If one or more threads have a non-zero si_signo in SIGINFO that will be used.
- If no threads had a SIGINFO block with a non-zero si_signo set all threads signals to the value in cursig in their PRSTATUS notes.
- If no thread has a signal set to a non-zero value set the signal for only the first thread to SIGSTOP.
This resolves two issues. The first was identified in bug 26322, the second became apparent while investigating this problem and looking at the signal values reported for each thread via “thread list”.
Firstly lldb is able to load core dumps generated by gcore where each thread has a SIGINFO note containing a signal number but cursig in the PRSTATUS block for each thread is 0.
Secondly if a SIGINFO note was found the “thread list” command will no longer show the same signal number for all threads. At the moment if a process crashes, for example with SIGILL, all threads will show “stop reason = signal SIGILL”. With this patch only the thread that executed the illegal instruction shows that stop reason. The other threads show “stop reason = signal 0”.
Reviewers: jingham, clayborg
Subscribers: sas, labath, lldb-commits
Differential Revision: https://reviews.llvm.org/D26676
llvm-svn: 287858
Summary:
The floating-point and SSE registers could be present in the elf-core
file in the note NT_FPREGSET for 64 bit ones, and in the note
NT_PRXFPREG for 32 bit ones.
The entire note is a binary blob matching the layout of the x87 save
area that gets generated by the FXSAVE instruction (see Intel developers
manual for more information).
This CL mainly modifies the RegisterRead function in
RegisterContextPOSIXCore_x86_64 for it to return the correct data both
for GPR and FPR/SSE registers, and return false (meaning "this register
is not available") for other registers.
I added a test to TestElfCore.py that tests reading FPR/SSE registers
both from a 32 and 64 bit elf-core file and I have inluded the source
which I used to generate the core files.
I tried to also add support for the AVX registers, because this info could
also be present in the elf-core file (note NT_X86_XSTATE - that is the result of
the newer XSAVE instruction). Parsing the contents from the file is
easy. The problem is that the ymm registers are split into two halves
and they are in different places in the note. For making this work one
would either make a "hacky" approach, because there won't be
any other way with the current state of the register contexts - they
assume that "this register is of size N and at offset M" and
don't have the notion of discontinuos registers.
Reviewers: labath
Subscribers: emaste, lldb-commits
Differential Revision: https://reviews.llvm.org/D26300
llvm-svn: 287506
On Windows, where we use Python 3 for testing, we have to be more explicit about converting between binary and string representations. I believe this should still work for Python 2, but I don't have a convenient way to try it out.
Differential Revision: https://reviews.llvm.org/D26643
llvm-svn: 286909
Summary: This patch reworks all the @skip... lines for sanitizer libraries to be based on whether or not the compiler actually works, rather than whether or not the compiler-rt sources are present in some magically derived directory.
Reviewers: lldb-commits
Subscribers: kubabrecka, tfiala
Differential Revision: https://reviews.llvm.org/D26513
llvm-svn: 286490
Summary:
r284830 added a summary provider for unique_ptr in libstdc++, whose value printed
the value of the pointee. This is a bit unintuitive as it becomes unobvious that
the value actually is a pointer, and we lose the way to actually obtain the
pointer value.
Change that to print the pointer value instead. The pointee value can still be
obtained through the synthetic children.
Reviewers: tberghammer, granata.enrico
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D26403
llvm-svn: 286355
Summary:
This commit disables the windows-only minidump plugin and enables the new
cross-platform plugin for windows minidump files. Test decorators are adjusted to
reflect that: windows minidump tests can now run on all platforms. The exception
is the tests that create minidump files, as that functionality is not available
yet. I've checked that this works on windows and linux.
Reviewers: amccarth, zturner
Subscribers: dvlahovski, lldb-commits
Differential Revision: https://reviews.llvm.org/D26393
llvm-svn: 286352
I added a "thread-stop-format" to distinguish between the form
that is just the thread info (since the stop printing immediately prints
the frame info) and one with more frame 0 info - which is useful for
"thread list" and the like.
I also added a frame.no-debug boolean to the format entities so you can
print frame information differently between frames with source info and those
without.
This closes https://reviews.llvm.org/D26383.
<rdar://problem/28273697>
llvm-svn: 286288
This renames the functionalities/postmortem/linux-core to elf-core and puts the
"linux" part into the individual names of the core files. Since the tests for
linux and freebsd core files are going to be very similar, having them close
together means they can reuse most of the plumbing.
llvm-svn: 286101
Summary:
This patch contains test for reading YMM Registers. The test basically
contains an inferior that loads the ymm registers with a bit pattern
and the python test executes register read to check if the bit pattern
is correctly written in the registers. This test is repeated twice for
each register with a different pattern for better sanity.
Reviewers: tberghammer, zturner, clayborg
Subscribers: tberghammer, danalbert, srhines
Differential Revision: https://reviews.llvm.org/D26242
llvm-svn: 285885
We really shouldn't be sending events for SB API's, dunno when we started
doing that. We don't do it for other things. But first restore the status quo.
llvm-svn: 285781
We don't have a good story for what happens to watchpoints when you don't
have a process, or if your process exits. Clearing that up will instruct
how to fix this for real.
Also added a test to make sure disable->enable works as well.
This resolves llvm.org/pr30789.
llvm-svn: 285742
Summary:
One of the tests was flaky, because similarly to
https://reviews.llvm.org/D18697 (rL265391) - if there is a process running
which is with the same PID as in the core file, the minidump
core file debugging will fail, because we get some information from the
running process.
The fix is routing the ProcessInfo requests through the Process class
and overriding it in ProcessMinidump to return correct data.
Reviewers: labath
Subscribers: lldb-commits, beanz
Differential Revision: https://reviews.llvm.org/D26193
llvm-svn: 285698
Summary:
This plugin resembles the already existing Windows-only Minidump plugin.
The WinMinidumpPlugin uses the Windows API for parsing Minidumps
while this plugin is cross-platform because it includes a Minidump
parser (which is already commited)
It is able to produce a backtrace, to read the general puprose regiters,
inspect local variables, show image list, do memory reads, etc.
For now the only arches that this supports are x86_32 and x86_64.
This is because I have only written register contexts for those.
Others will come in next CLs.
I copied the WinMinidump tests and adapted them a little bit for them to
work with the new plugin (and they pass)
I will add more tests, aiming for better code coverage.
There is still functionality to be added, see TODOs in code.
Reviewers: labath, zturner
Subscribers: beanz, mgorny, modocache, lldb-commits, amccarth
Differential Revision: https://reviews.llvm.org/D25905
llvm-svn: 285587
Summary:
Convert tests using LLDB headers to use generateSource to put the right include paths in place regardless of whether or not you're building a framework.
This also abstracted generateSource out of TestPublicAPIHeaders.py into lldbtest.py.
Reviewers: tfiala, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D25887
llvm-svn: 285542
This reverts commit r285357.
I committed this patch accidentally out of order. Will recommit when the change this depends on is landed.
llvm-svn: 285361
Summary:
Convert tests using LLDB headers to use generateSource to put the right include paths in place regardless of whether or not you're building a framework.
This also abstracted generateSource out of TestPublicAPIHeaders.py into lldbtest.py.
Reviewers: tfiala, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D25887
llvm-svn: 285357
Summary:
Check whether the setting the breakpoint failed during instruction emulation. If
it did, the next pc is likely in unmapped memory, and the inferior will crash
anyway after the next instruction. Do not return an error in this case, but just
continue stepping.
Reenabled the crash during step test for android/linux.
Reviewers: labath
Subscribers: aemerson, rengolin, tberghammer, danalbert, srhines, lldb-commits
Differential Revision: https://reviews.llvm.org/D25926
Author: Jason Majors <jmajors@google.com>
llvm-svn: 285187
Otherwise, they tend to generate filename too long errors.
They already contain the same test name in the directory, file, and class names,
so no information is really lost here.
llvm-svn: 284987
* Display the strong/weak count in the summary
* Display the pointed object as a synthetic member
* Create synthetic children for weak/strong count
Differential revision: https://reviews.llvm.org/D25726
llvm-svn: 284828
This tests that lldb handles the situation when a single instruction triggers
multiple watchpoint hits. It currently fails on arm due to what appears to be a
lldb-server bug (pr30758).
llvm-svn: 284819
This reverts commit r284795, as it breaks watchpoint handling on arm (and
presumable all architectures that report watchpoint hits without executing the
tripping instruction).
There seems to be something fundamentally wrong with this patch: it uses
process_sp->AddPreResumeAction to re-enable the watchpoint, but the whole point
of the step-over-watchpoint logic (which AFAIK is the only user of this class) is
to disable the watchpoint *after* we resume to do the single step.
I have no idea how to fix this except by reverting the offending patch.
llvm-svn: 284817
Also, watchpoint commands, like breakpoint commands, need to run in async mode.
This was causing intermittent failures in TestWatchpointCommandPython.py, which is now solid.
llvm-svn: 284795
by grubbing the break list output. If you pass a number of locations into
the run_break_* functions, they will check that this is right for you.
llvm-svn: 284791
This patch fixes ARM/AArch64 watchpoint bug which was taking inferior out of control while stepping over watchpoints.
Also adds a test case that tests above problem.
Differential revision: https://reviews.llvm.org/D25057
llvm-svn: 284706
Pavel Labath