Using the "run_to_{source,name}_breakpoint will allow us to remove
a lot of boiler-plate from the testsuite. We mostly use source
breakpoints, but some tests use by name ones so this was needed.
llvm-svn: 324010
The mock server was sending acks back in response to spurious acks from
the client, but the client was not prepared to handle these. Most of the
time this would work because the only time the client was sending
unsolicited acks is after the initial connection, and there reply-ack
would get ignored in the "flush all packets from the server" loop which
came after the ack. However, this loop had only a 10ms delay, and
sometimes this was not enough to catch the reply (which meant the
connection got out of sync, and test failed).
Since this behavior not consistent with how lldb-server handles this
situation (it just ignores the ack), I fix the mock server to do the
same.
llvm-svn: 323953
This patch is the result of a discussion on lldb-dev, see
http://lists.llvm.org/pipermail/lldb-dev/2018-January/013111.html for
background.
For each test (should be eventually: each test configuration) a
separate build directory is created and we execute
make VPATH=$srcdir/path/to/test -C $builddir/path/to/test -f $srcdir/path/to/test/Makefile -I $srcdir/path/to/test
In order to make this work all LLDB tests need to be updated to find
the executable in the test build directory, since CWD still points at
the test's source directory, which is a requirement for unittest2.
Although we have done extensive testing, I'm expecting that this first
attempt will break a few bots. Please DO NOT HESITATE TO REVERT this
patch in order to get the bots green again. We will likely have to
iterate on this some more.
Differential Revision: https://reviews.llvm.org/D42281
llvm-svn: 323803
Summary:
Adds new utilities that make it easier to write test cases for lldb acting as a client over a gdb-remote connection.
- A GDBRemoteTestBase class that starts a mock GDB server and provides an easy way to check client packets
- A MockGDBServer that, via MockGDBServerResponder, can be made to issue server responses that test client behavior.
- Utility functions for handling common data encoding/decoding
- Utility functions for creating dummy targets from YAML files
----
Split from the review at https://reviews.llvm.org/D42145, which was a new feature that necessitated the new testing capabilities.
Reviewers: clayborg, labath
Reviewed By: clayborg, labath
Subscribers: hintonda, davide, jingham, krytarowski, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D42195
Patch by Owen Shaw <llvm@owenpshaw.net>
llvm-svn: 323636
TestLibcxxListLoop - fails because the evil "define private public"
trick does not work with gmodules. The purpose of the test is not to
test debug info parsing so I just mark it as no_debug_info_testcase.
In the long term it may be interesting to write a mock std::list which
will allow us to test bad inputs to data formatters more easily.
TestGModules - seems to be a genuine bug. Filed pr36107 and xfailed.
llvm-svn: 323520
This test #include's stdio.h, which, on at least two bots results in a
module import of MacTypes.h (due to weird SDK layering issues), which
causes the test to fail to compile.
Just don't #include stdio.h, as it's not needed for the test.
llvm-svn: 323467
Stale global module caches cause problems for the bots. The modules
become invalid when clang headers are updated by version control, and
tests which use these modules fail to compile, e.g:
fatal error: file '.../__stddef_max_align_t.h' has been modified since the module file '/var/.../Darwin.pcm' was built
note: please rebuild precompiled header '/var/.../Darwin.pcm'
Eventually we should transition to having just a single module cache to speed
tests up. This patch should be just enough to fix the spurious bot failures due
to stale caches.
rdar://36479805, also related to llvm.org/PR36048
Differential Revision: https://reviews.llvm.org/D42277
llvm-svn: 323450
RemoveInvalidLocations was clearing out the m_locations in the
breakpoint by hand, and it wasn't also clearing the locations from
the address->location map, which confused us when we went to update
breakpoint locations.
I also made Breakpoint::ModulesChanged check the Location's Section
to make sure it hadn't been deleted. This shouldn't strictly be necessary,
but if the DynamicLoaderPlugin doesn't do it's job right (I'm looking at
you new Darwin DynamicLoader...) then it can end up leaving stale locations
on rerun. It doesn't hurt to clean them up here as a backstop.
<rdar://problem/36134350>
llvm-svn: 322348
When rendezvous structure is not initialized we need to set up
rendezvous breakpoint anyway. In this case the code will locate
dynamic loader (interpreter) and look for known function names.
This is r322209, but with fixed VDSO loading fixed.
Bug: https://bugs.llvm.org/show_bug.cgi?id=25806
Differential Revision: https://reviews.llvm.org/D41533
llvm-svn: 322251
When rendezvous structure is not initialized we need to set up
rendezvous breakpoint anyway. In this case the code will locate
dynamic loader (interpreter) and look for known function names.
Bug: https://bugs.llvm.org/show_bug.cgi?id=25806
Differential Revision: https://reviews.llvm.org/D41533
llvm-svn: 322209
an empty Python string object when it reads a 0-length
string out of memory (and a successful SBError object).
<rdar://problem/26186692>
llvm-svn: 321338
Also add a test. There should also be control for this
in ProcessLaunchInfo and a "target launch" flag, but at least
this will allow you to control it somehow.
<rdar://problem/35842137>
llvm-svn: 319731
Summary:
This flag is on by default for darwin and freebsd, but off for linux.
Without it, clang will sometimes not emit debug info for types like
std::string. Whether it does this, and which tests will fail because of
that depends on the linux distro and c++ library version.
A bunch of tests were already setting these flags manually, but here
instead I take a whole sale approach and enable this flag for all tests.
Any test which does not want to have this flag (right now we have one
such test) can turn it off explicitly via
CFLAGS_EXTRAS+=$(LIMIT_DEBUG_INFO_FLAGS)
This fixes a bunch of data formatter tests on red-hat.
Reviewers: davide, jankratochvil
Subscribers: emaste, aprantl, krytarowski, JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D40717
llvm-svn: 319653
unambiguously on one bit of code. On macOS these
lines mapped to two distinct locations, and that
was artificially throwing off the test.
llvm-svn: 319472
Summary:
New linux kernels (on systems that support the XSAVES instruction) will
not update the inferior registers unless the corresponding flag in the
XSAVE header is set. Normally this flag will be set in our image of the
XSAVE area (since we obtained it from the kernel), but if the inferior
has never used the corresponding register set, the respective flag can
be clear.
This fixes the issue by making sure we explicitly set the flags
corresponding to the registers we modify. I don't try to precisely match
the flags to set on each write, as the rules could get quite complicated
-- I use a simpler over-approximation instead.
This was already caught by test_fp_register_write, but that was only
because the code that ran before main() did not use some of the register
sets. Since nothing in this test relies on being stopped in main(), I
modify the test to stop at the entry point instead, so we can be sure
the inferior did not have a chance to access these registers.
Reviewers: clayborg, valentinagiusti
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D40434
llvm-svn: 319161
r317561 exposed an interesting bug (pr35228) in handling of simultaneous
watchpoint hits. Disabling the test until we can get that fixed.
llvm-svn: 317683
Summary:
The test incremented an atomic varible to trigger the watchpoint event.
On arm64 this compiled to a ldaxr/stlxr loop, with the watchpoint being
triggered in the middle of the loop. Hitting the watchpoint resets the
exclusive monitor, and forces the process to loop one more time, hitting
the watchpoint again, etc.
While it would be nice if the debugger was able to resume from this
situation, this is not trivial, and is not what this test is about.
Therefore, I propose to change this to a simple store to a normal
variable (which should still trip the watchpoint everywhere, but without
atomic loops) and file a bug to investigate the possibilities of
handling the watchpoints in atomic loops in a more reasonable way.
Reviewers: clayborg
Subscribers: aemerson, kristof.beyls, lldb-commits
Differential Revision: https://reviews.llvm.org/D39680
llvm-svn: 317561
Summary:
This mechanism was mostly redundant with the file-based .categories
mechanism, and it was interfering with it, as any test which implemented
a getCategories method would not inherit the filesystem categories.
This patch removes it. The existing categories are preserved either by
adding a .categories file, or using the @add_test_categories decorator.
Reviewers: jingham, clayborg, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D39515
llvm-svn: 317277
Now that the wathpoint tests have their own category, we can easily skip
them on devices which don't have watchpoint support. Therefore, we don't
need an android xfail on each of these tests.
llvm-svn: 317276
Summary:
std::queue is just a fancy wrapper around another container, so all we
need to do is to delegate to the it.
Reviewers: jingham, EricWF
Subscribers: srhines, mgorny, lldb-commits, eugene
Differential Revision: https://reviews.llvm.org/D35666
llvm-svn: 317099
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
