| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The inferior was sleeping before doing any interesting work. I remove that
to make the test faster.
While looking at the purpose of the test (to check that watchpoints are
propagated to all existing threads - r140757) I noticed that the test has
diverged from the original intention and now it creates the threads *after* the
watchpoint is set (this probably happened during the std::thread refactor).
After some discussion, we decided both scenarios make sense, so I modify the
test to test both.
The watchpoint propagation functionality is not really debug info depenent, so
I also stop replication of this test. This brings the test's time from ~108s
down to 4s.
Reviewers: davide, jingham
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D43857
llvm-svn: 326514
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Merge branch 'master' into adaptPPC64tests
Reviewers: clayborg, alexandreyy, labath
Reviewed By: clayborg, alexandreyy
Subscribers: luporl, lbianc, alexandreyy, lldb-commits
Differential Revision: https://reviews.llvm.org/D42917
Patch by Ana Julia Caetano <ana.caetano@eldorado.org.br>.
llvm-svn: 326369
|
|
|
|
|
|
|
|
|
|
|
|
| |
regions"
This reverts commit r326261 as it introduces inconsistencies in the
handling of load addresses for ObjectFileELF -- some parts of the class
use physical addresses, and some use virtual. This has manifested itself
as us not being able to set the load address of the vdso "module" on
android.
llvm-svn: 326367
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When writing an object file over gdb-remote, use the vFlashErase, vFlashWrite, and vFlashDone commands if the write address is in a flash memory region. A bare metal target may have this kind of setup.
- Update ObjectFileELF to set load addresses using physical addresses. A typical case may be a data section with a physical address in ROM and a virtual address in RAM, which should be loaded to the ROM address.
- Add support for querying the target's qXfer:memory-map, which contains information about flash memory regions, leveraging MemoryRegionInfo data structures with minor modifications
- Update ProcessGDBRemote to use vFlash commands in DoWriteMemory when the target address is in a flash region
Original discussion at http://lists.llvm.org/pipermail/lldb-dev/2018-January/013093.html
Reviewers: clayborg, labath
Reviewed By: labath
Subscribers: arichardson, emaste, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D42145
Patch by Owen Shaw <llvm@owenpshaw.net>
llvm-svn: 326261
|
|
|
|
|
|
|
|
|
| |
These tests all test very similar things, and use the same inferior.
They were only placed in separate folders to achieve better
paralelization. Now that we paralelize at a file level, this is no
longer relevant, and we can put them together again.
llvm-svn: 326159
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
use it
Summary:
The command takes two input arguments: a module to use as a debug target
and a file containing a list of commands. The command will execute each
of the breakpoint commands in the file and dump the breakpoint state
after each one.
The commands are expected to be breakpoint set/remove/etc. commands, but
I explicitly allow any lldb command here, so you can do things like
change setting which impact breakpoint resolution, etc. There is also a
"-persistent" flag, which causes lldb-test to *not* automatically clear
the breakpoint list after each command. Right now I don't use it, but
the idea behind it was that it could be used to test more complex
combinations of breakpoint commands (set+modify, set+disable, etc.).
Right now the command prints out only the basic breakpoint state, but
more information can be easily added there. To enable easy matching of
the "at least one breakpoint location found" state, the command
explicitly prints out the string "At least one breakpoint location.".
To enable testing of breakpoints set with an absolute paths, I add the
ability to perform rudimentary substitutions on the commands: right now
the string %p is replaced by the directory which contains the command
file (so, under normal circumstances, this will perform the same
substitution as lit would do for %p).
I use this command to rewrite the TestBreakpointCaseSensitivity test --
the test was checking about a dozen breakpoint commands, but it was
launching a new process for each one, so it took about 90 seconds to
run. The new test takes about 0.3 seconds for me, which is approximately
a 300x speedup.
Reviewers: davide, zturner, jingham
Subscribers: luporl, lldb-commits
Differential Revision: https://reviews.llvm.org/D43686
llvm-svn: 326112
|
|
|
|
|
|
| |
PR36435
llvm-svn: 325958
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Potentially due to the recent testuite refactorings, this test now reports
a full absolute path but expect just the filename. For some reason this
test is skipped on GreenDragon so we've never seen the issue.
Reviewers: vsk
Subscribers: kubamracek, lldb-commits
Differential Revision: https://reviews.llvm.org/D43577
llvm-svn: 325859
|
|
|
|
|
|
|
| |
The length field of an NSConcreteData lives one word past the start of
the object, not two.
llvm-svn: 325841
|
|
|
|
|
|
|
|
|
|
| |
The header file for the DLL tried to declare inline functions and a local
function as dllexport which broke the compile and link. Removing the bad
declarations solves the problem, and the test passes on Windows now.
Differential Revision: https://reviews.llvm.org/D43600
llvm-svn: 325836
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This test was failing on Windows because it expected the breakpoint in the
dynamic library to be resolved before the process is launched. Since the DLL
isn't loaded until the process is launched this didn't work.
The fix creates a special value (-2) for num_expected_locations that ignores
the actual number of breakpoint locations found.
Reviewers: jasonmolenda
Subscribers: sanjoy, lldb-commits
Differential Revision: https://reviews.llvm.org/D43419
llvm-svn: 325704
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
These were not being flaky, but they're still making the tree dirty.
These tests were using lldbutil.append_to_process_working_directory to
derive the file path so I fix them by modifying the function to return
the build directory for local tests.
Technically, now the path returned by this function does not point to
the process working directory for local tests, but I think it makes
sense to keep the function name, as I think we should move towards
launching the process in the build directory (and I intend to change
this for the handful of inferiors that actually care about their PWD,
for example because they need to create files there).
Reviewers: davide, aprantl
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D43506
llvm-svn: 325690
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The paralelization patch exposed a bunch of cases where we were still
touching the source tree (as these tests were now stepping on each
others toes and being flaky).
This patch removes such issues from breakpoint command tests. Since the
only reason they were creating files was to indirectly test whether the
breakpoint commands got executed (and plumbing the full build tree path
to all places that needed it would be messy) I decided to modify the
tests to check for a different side effect instead: modification of a
global variable. This also makes the code simpler as checking the value
of the global variable is easier, and there is nothing to clean up.
As the tests aren't really doing anything debug-info related, I took the
opportunity to also mark them as NO_DEBUG_INFO_TESTCASEs.
Reviewers: jingham, aprantl
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D43464
llvm-svn: 325570
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This adds a SBDebugger::GetBuildConfiguration static function, which
returns a SBStructuredData describing the the build parameters of
liblldb. Right now, it just contains one entry: whether we were built
with XML support.
I use the new functionality to skip a test which requires XML support,
but concievably the new function could be useful to other liblldb
clients as well (making sure the library supports the feature they are
about to use).
Reviewers: zturner, jingham, clayborg, davide
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D43333
llvm-svn: 325504
|
|
|
|
|
|
|
|
|
|
|
| |
These were missed in the great refactor because they were added
concurrently with it. Since we started running tests in a more parallel
fashion they started to be flaky. This should fix it.
Now that we are no longer polluting the source tree, I also delete the
bit of custom cleanup code specific to these tests.
llvm-svn: 325495
|
|
|
|
|
|
| |
The test does not actually connect to any remote targets.
llvm-svn: 325250
|
|
|
|
|
|
|
| |
It wasn't python leaking, it was lldb. Thanks to Pavel for the
explanation. Pointy-hat to me.
llvm-svn: 324919
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This test uses XML packets, but libxml is an optional dependency of
lldb, and this test fails if it is not present.
I'm leaving this enabled on mac, as thats the only platform that's
likely to have libxml always available, but ideally we should have a way
to skip this based on build configuration. I'll see if I can whip
something like that up soon, but for the time being, this unblocks the
buildbots.
llvm-svn: 324870
|
|
|
|
|
|
|
|
|
| |
arch incompat with spec in file so it's rejected and the test fails.
will look into this later, will be a test case issue not a test issue;
test case may only be valid when lldb is built for/running on an x86_64
system.
llvm-svn: 324795
|
|
|
|
|
|
| |
target.xml packet if it is included.
llvm-svn: 324792
|
|
|
|
|
|
|
|
|
| |
This only worked on MacOS, which now ships a newer version of
python without this bug. As such, we don't leak the fd, and
this test is not needed anymore (as it also hardcoded the python
version in the check).
llvm-svn: 324743
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Update makefiles to specify -fPIC in Makefile.rules and only throw -fPIC when building a shared library. This change is necessary to allow building the lldb tests on Windows where -fPIC is not a valid option.
Update a few places to Python 3.x syntax
Reviewers: zturner, lldb-commits
Reviewed By: zturner
Subscribers: stella.stamenova, labath, llvm-commits
Differential Revision: https://reviews.llvm.org/D42994
llvm-svn: 324671
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The test was trying to reproduce a bug in handling of two concurrent
events, which was impossible to do reliably in a black-box style test.
In practice, this meant the test was only ever failing on remote
targets, as these were slow enough to trigger this.
Fortunately, we now have the ability to mock the server side of the
connection, which means we can simulate the failure deterministically,
so I rewrite the test to use the new gdb-client framework.
I've needed to add a couple of new packets to the mock server to be able
to do this. Instead of trying to guess how a "typical" gdb-client test
will want to handle this, I throw an exception in the implementation to
force the user to override them (the packets are only sent if the test
explicitly performs some action which will trigger them, so a basic test
which e.g. does not need the "continue" functionality will not need to
implement them).
Reviewers: owenpshaw
Subscribers: srhines, lldb-commits
Differential Revision: https://reviews.llvm.org/D42959
llvm-svn: 324590
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
lock file
This patch creates a <test>.dwarf, <test>.dwo, etc., build directory for each testcase variant.
Most importantly, this eliminates the need for the per-test lock file in the source directory.
Tests that are marked as NO_DEBUG_INFO_TESTCASE and build with
buildDefault() are built in a <test>.default build directory.
Differential Revision: https://reviews.llvm.org/D42763
llvm-svn: 324368
|
|
|
|
| |
llvm-svn: 324288
|
|
|
|
|
|
|
| |
We've had a bug (fixed by https://reviews.llvm.org/D42828) where the
thread name was being read incorrectly. Add a test for this behavior.
llvm-svn: 324230
|
|
|
|
|
|
|
|
| |
This test was marked as an expected failure because of PR20231 but it
seems to consistently result in an unexpected success across the bots.
Let's try to re-enable this test again.
llvm-svn: 324227
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This changes the way we store the debug info variant to make it
available earlier in the test bringup: instead of it being set by the
test wrapper method, it is set as a *property* of the wrapper method.
This way, we can inspect it as soon as self.testMethodName is
initialized. The retrieval is implemented by a new function
TestBase.getDebugInfo(), and all that's necessary to make it work is to
change self.debug_info into self.getDebugInfo().
While searching for debug_info occurences i noticed that TestLogging is
being replicated for no good reason, so I removed the replication there.
Reviewers: aprantl, jingham
Subscribers: eraman, JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D42836
llvm-svn: 324226
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
This fails regardless of the android architecture or compiler used. The
important bit is the mismatch in path separators.
llvm-svn: 323974
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 323917
|
|
|
|
| |
llvm-svn: 323808
|
|
|
|
| |
llvm-svn: 323805
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
and fix resulting errors. This is a prerequisite for building each
test variant in its own build directory.
llvm-svn: 323789
|
|
|
|
|
|
|
| |
Another step towards enabling unexpected successes as failures
by default.
llvm-svn: 323707
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 323537
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
in TestBase::getBuildArtifact(). This NFC commit is in preparation for
https://reviews.llvm.org/D42281 (compile the LLDB tests out-of-tree).
Differential Revision: https://reviews.llvm.org/D42280
llvm-svn: 323007
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
This reverts commit r322209, because it broke
TestNoreturnUnwind,TestInferiorAssert and TestNumThreads on i386.
llvm-svn: 322229
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 322054
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
When building with cmake on green gragon or on ci.swift.org, this test fails.
rdar://problem/36134350
llvm-svn: 321095
|