Summary:
When running on an architecture other than x86_64, the
target.ConnectRemote() part of the test may add platform information to
the target triple.
It was observed that this happens at Process::CompleteAttach() method,
after the platform_sp->IsCompatibleArchitecture() check fails.
This method then calls platform_sp->GetPlatformForArchitecture(), that
on a Linux machine ends up returning a generic Linux platform, that then
ends up getting added to the original target architecture.
Reviewers: clayborg, labath, jasonmolenda
Reviewed By: labath
Subscribers: alexandreyy, lbianc
Differential Revision: https://reviews.llvm.org/D44022
Patch by Leandro Lupori <leandro.lupori@gmail.com>.
llvm-svn: 327981
Summary:
- Fix test jump for powerpc64le
Jumping directly to the return line on power architecture dos not means
returning the value that is seen on the code. The last test fails, because
it needs the execution of some assembly in the beginning of the function.
Avoiding this test for this architecture.
- Avoid evaluate environ variable name on Linux
On Linux the Symbol environ conflicts with another variable, then in
order to avoid it, this test was moved into a specific test, which is not
supported if the OS is Linux.
- Added PPC64le as MIPS behavior
Checking the disassembler output, on PPC64le machines behaves as MPIS.
Added method to identify PPC64le architecture and checking it when
disassembling instructions in the test case.
Reviewers: labath
Reviewed By: labath
Subscribers: clayborg, labath, luporl, alexandreyy, sdardis, ki.stfu, arichardson
Differential Revision: https://reviews.llvm.org/D44101
Patch by Leonardo Bianconi <leonardo.bianconi@eldorado.org.br>.
llvm-svn: 327977
The difference between this and the previous patch is that now we use
ELF physical addresses only for loading objects into the target (and the
rest of the module load address logic still uses virtual addresses).
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: llvm-commits, arichardson, emaste, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D42145
Patch by Owen Shaw <llvm@owenpshaw.net>.
llvm-svn: 327970
Summary:
When in a gmodules-like debugging scenario, you can have a parent decl context
that gets imported from an external AST. When this happens, we must be careful
to complete this type before adding children to it, otherwise it sometimes
results in a crash.
Reviewers: clayborg, jingham
Subscribers: aprantl, JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D43592
llvm-svn: 327750
Summary:
This patch implements a unified way of cleaning the build folder of each
test. This is done by completely removing the build folder before each
test, in the respective setUp() method. Previously, we were using a
combination of several methods, each with it's own drawbacks:
- nuking the entire build tree before running dotest: the issue here is
that this did not take place if you ran dotest manually
- running "make clean" before the main "make" target: this relied on the
clean command being correctly implemented. This was usually true, but
not always.
- for files which were not produced by make, each python file was
responsible for ensuring their deleting, using a variety of methods.
With this approach, the previous methods become redundant. I remove the
first two, since they are centralized. For the other various bits of
clean-up code in python files, I indend to delete it when I come
across it.
Reviewers: aprantl
Subscribers: emaste, ki.stfu, mgorny, eraman, lldb-commits
Differential Revision: https://reviews.llvm.org/D44526
llvm-svn: 327703
This test started failing after r327625. The cause seems difference in the
treatment of relative --stdin paths between MacOS (debugserver?) and linux
(lldb-server?). Linux treats this as relative to the debuggers PWD, while MacOS
as relative to (I think) the future PWD of the launched process.
This fixes the issue by using absolute paths, which should work everywhere, but
we should probably unify this path handling as well. I'll ask around about what
is the expected behavior here.
llvm-svn: 327633
Summary:
The changes here fall into several categories.
- some tests were redirecting inferior stdout/err to a file. For these I
make sure we use an absolute path for the file. I also create a
lldbutil.read_file_on_target helper function to encapsulate the
differences between reading a file locally and remotely.
- some tests were redirecting the pexpect I/O into a file. For these I
use a python StringIO object to avoid creating a file altogether.
- the TestSettings inferior was creating a file. Here, I make sure the
inferior is launched with pwd=build-dir so that the files end up
created there.
- lldb-mi --log (used by some tests) creates a log file in PWD without
the ability say differently. To make this work I make sure to run
lldb-mi with PWD=build_dir. This in turn necessitated a couple of
changes in other lldb-mi tests, which were using relative paths to
access the source tree.
Reviewers: aprantl
Subscribers: ki.stfu, mehdi_amini, lldb-commits
Differential Revision: https://reviews.llvm.org/D44159
llvm-svn: 327625
When using:
(lldb) settings set target.source-map ./ /path/to/source
LLDB would fail to set a source file and line breakpoint with:
(lldb) breakpoint set --file /path/to/source/main.c --line 2
Because code in the target was undoing the remapping of "/path/to/source/main.c" to "./main.c" and then it would resolve this path, which would append the current working directory to the path. We don't want to resolve paths that we unmap.
Test case added.
Differential Revision: https://reviews.llvm.org/D44502
llvm-svn: 327600
Until we have a better story for putting commands and check lines
in the same file (they're currently ignored), it seems that inline
tests are actually more concise and easier to understand.
Too bad we have still some python boilerplate, but that's not
really substantial so we can live with it.
Thanks to Fred for pointing out and Jim for explaining me how
to use the inline test format.
<rdar://problem/34806516>
llvm-svn: 327592
This is a first pass at removing some lldb-mi tests which have been
xfailed and unmaintained for a while. We have open PRs for most of these
tests already. I've opened up the following additional PRs:
llvm.org/PR36739 - lldb-mi driver exits properly
llvm.org/PR36740 - lldb-mi -gdb-set and -gdb-show
llvm.org/PR36741 - lldb-mi -symbol-xxx
The motivation here is to address timeout and pexpect-related issues in
the test suite. This was discussed on lldb-dev in the thread: "increase
timeout for tests?".
After this change, the lldb-mi tests seem to be in better health (on
Darwin at least). I consistently get:
$ ./bin/llvm-dotest -p TestMi
===================
Test Result Summary
===================
Test Methods: 101
Reruns: 0
Success: 88
Expected Failure: 0
Failure: 0
Error: 0
Exceptional Exit: 0
Unexpected Success: 0
Skip: 13
Timeout: 0
Expected Timeout: 0
llvm-svn: 327552
The OS plugins might have updated the thread list after a core file has
been loaded. The physical thread in the core file may no longer be the
one that should be selected. Hence we should run the thread selection
logic after loading the core.
Differential revision: https://reviews.llvm.org/D44139
llvm-svn: 327501
The expression-hits tracking logic is not available on any platform. The
reason this tests happens to pass on some platforms is that the test is
written poorly -- it relies on the fact that post-main cleanup code will
write to the stack memory once occupied by the watched variable, but
this is not the case everywhere (e.g. linux glibc does not seem to do
this, but android's bionic library does).
llvm-svn: 327483
This is a more principled approach to disabling Spotlight .dSYM
lookups while running the testsuite, most importantly it also works
for the LIT-based tests, which I overlooked in my initial fix
(renaming the test build dir to lldb-tests.noindex).
Differential Revision: https://reviews.llvm.org/D44342
llvm-svn: 327330
I want to extend the properties on ModuleList to also contain other
more general settings and renaming the settings category to symbols
seems to be the least bad of choices.
llvm-svn: 327193
The test I added in r327110 is failing on windows because of "import
pexpect". However, this import is no longer necessary as these tests
don't use pexpect anymore.
In fact, it seems that all TestCompletion tests are passing on windows
after this, so I enable all of them.
llvm-svn: 327133
Summary:
The args class is used in plenty of places (a lot of them in the lower lldb
layers) for representing a list of arguments, and most of these places don't
care about option parsing. Moving the option parsing out of the class removes
the largest external dependency (there are a couple more, but these are in
static functions), and brings us closer to being able to move it to the
Utility module).
The new home for these functions is the Options class, which was already used
as an argument to the parse calls, so this just inverts the dependency between
the two.
The functions are themselves are mainly just copied -- the biggest functional
change I've made to them is to avoid modifying the input Args argument (getopt
likes to permute the argument vector), as it was weird to have another class
reorder the entries in Args class. So now the functions don't modify the input
arguments, and (for those where it makes sense) return a new Args vector
instead. I've also made the addition of a "fake arg0" (required for getopt
compatibility) an implementation detail rather than a part of interface.
While doing that I noticed that ParseForCompletion function was recording the
option indexes in the shuffled vector, but then the consumer was looking up the
entries in the unshuffled one. This manifested itself as us not being able to
complete "watchpoint set variable foo --" (because getopt would move "foo" to
the end). Surprisingly all other completions (e.g. "watchpoint set variable foo
--w") were not affected by this. However, I couldn't find a comprehensive test
for command argument completion, so I consolidated the existing tests and added
a bunch of new ones.
Reviewers: davide, jingham, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D43837
llvm-svn: 327110
There is a mailing list discussion re: r325927 about why this test fails
in the dsym variant. I've marked it skipped for now, until the issue is
resolved.
llvm-svn: 327089
The test "test_fp_special_purpose_register_read" in TestRegisters.py
fails on Darwin machines configured to use an out-of-tree debugserver.
The error message is: 'register read ftag' returns expected result, got
'ftag = 0x80'. This indicates that the debugserver in use is too old.
This commit introduces a decorator which can be used to skip tests which
rely on having a just-built debugserver. This resolves the issue:
$ ./bin/llvm-dotest -p TestRegisters.py -v
1 out of 617 test suites processed - TestRegisters.py
Test Methods: 7
Success: 6
Skip: 1
...
llvm-svn: 327052
Summary:
On PPC64, the tested functions were being entered through their local entry point, while the tests expected the program to stop at the function start address, that, for PPC64, corresponds to the global entry point.
To fix the issue, the test program was modified to call the functions to be tested through function pointers, which, on PPC64, force the calls through the global entry point, while not affecting the test on other platforms.
Reviewers: clayborg, labath
Reviewed By: labath
Subscribers: alexandreyy, lbianc
Differential Revision: https://reviews.llvm.org/D43768
Patch by Leandro Lupori <leandro.lupori@gmail.com>.
llvm-svn: 327013
Test that "lldb-mi --interpreter" can interpret "target list" CLI command.
Patch by Alex Polyakov!
Differential Revision: https://reviews.llvm.org/D44040
llvm-svn: 326847
Summary:
The test was failing in remote debugging scenario with windows as a host
as cmd.exe is not able to parse the complicated shell commands in the
Makefile.
The test seemed like a perfect candidate for a more focused testing
approach, so I have rewritten in on top of lldb-test's module-sections
functionality. The slight gotcha there was that the
Module::GetSectionList does not include the sections from the symbol
file until someone manually calls Module::GetSymbolVendor. Normally,
this is not an issue, because someone will have initialized the symbol
vendor by the time anyone starts looking at the sections. However, when
all one this is dump the section list, we run into this problem.
I've tried making this behavior more automatic, but it turns out it's
not that easy, so for now, I just manually initialize the Symbol Vendor
before dumping out the sections in lldb-test.
Reviewers: jankratochvil
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D42914
llvm-svn: 326805
Summary:
- reg_nums were missing the end marker entry
- marked FP test to be skipped for ppc64
Reviewers: labath, clayborg
Reviewed By: labath, clayborg
Subscribers: alexandreyy, lbianc, nemanjai, kbarton
Differential Revision: https://reviews.llvm.org/D43767
Patch by Leandro Lupori <leandro.lupori@gmail.com>
llvm-svn: 326775
were originally written by Chris Bieneman, they've undergone a
number of changes since then.
Also including the debugserver bridgeos support, another arm
environment that runs Darwin akin to ios. These codepaths are
activated when running in a bridgeos environment which we're not
set up to test today.
There's additional (small) lldb changes to handle bridgeos binaries
that still need to be merged up.
Tested on a darwin system with avx512 hardware and without.
<rdar://problem/36424951>
llvm-svn: 326756
These tests fail with a relatively frequently on Darwin machines with
errors such as:
File ".../lldb/third_party/Python/module/pexpect-2.4/pexpect.py", line 1444, in expect_loop
raise EOF(str(e) + '\n' + str(self))
EOF: End Of File (EOF) in read_nonblocking(). Empty string style platform.
The unpredictable failures make these tests noisy.
rdar://37046976
llvm-svn: 326739
It turns out that setting the clang module cache after LLDB has a
Target can be too late. In particular, the Swift language plugin needs
to know the setting without having access to a Target. This patch
moves the setting into the *LLDB* module cache, where it is a global
setting that is available before any Target is created and more
importantly, is shared between all Targets.
rdar://problem/37944432
Differential Revision: https://reviews.llvm.org/D43984
llvm-svn: 326628
Adding categories to inline tests does not work because the attribute
is set at the function level. For methods, this means it applies to all
instances of that particular class. While this is what we want in most
cases, it's not for inline tests, where different instances correspond
to different tests.
With the workaround in place, assigning a category to one test resulted
in the category applied to *all* inline tests.
This patch removes the workaround and throws an exception with an
informative error message, to prevent this from happening in the future.
llvm-svn: 326552
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
gcc will say that the type of "this" is "T * const", clang "T *".
Compare the unqualified type names to erase the difference between the
two, as the constness is not a part of this test.
FWIW, I think that the gcc behavior makes more sense here.
llvm-svn: 326449
Before the change to compile tests out-of-tree, the cleanup classmethod
in TestQuoting.py would remove a temp file. After the change it threw an
exception due to a malformed call to getBuildArtifact().
Bring back the old behavior.
llvm-svn: 326414
There's a bug in FindTypes, it ignores the exact flag if you pass a name that doesn't begin with
:: and pass eTypeClassAny for the type.
In this case we always know that the name we get from the vtable name is absolute so we can
work around the bug by prepending the "::". This doesn't fix the FindTypes bug.
<rdar://problem/38010986>
llvm-svn: 326412
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
r326140 exposed the fact that we are not actually running inline tests on
remote targets. The tests fail to launch the inferior in the first place
because they passed an invalid working directory to the launch function.
This should fix that.
llvm-svn: 326264
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
This test contained a copy of the inferior used by most of llgs test.
This was done to enable better paralelization, but now it's irrelevant.
llvm-svn: 326218
Further investigation required; tests will be enabled on the buildbot
worker soon. Marking failing tests for now in order to start with a
green buildbot while investigation takes place.
This is a recommit of r326134, with the required import added.
llvm.org/pr36527
llvm-svn: 326166
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
When writing an inline test, there is no way to make sure that any of
the inline commands are actually executed, so this patch adds a sanity
check that at least one breakpoint was hit. This avoids a test with no
breakpoints being hit passing.
Differential Revision: https://reviews.llvm.org/D43694
llvm-svn: 326140
Further investigation required; tests will be enabled on the buildbot
worker soon. Marking failing tests for now in order to start with a
green buildbot while investigation takes place.
llvm.org/pr36527
llvm-svn: 326134
Without this fix, the test ERRORs because the link of the inferior fails. This
patch adds the LLDB_TEST_API macro where needed and uses the new -2 magic
value for num_expected_locations to account for lazy-loading of module symbols
on Windows.
With this fix, the test itself still fails: conflicting_symbol isn't in the
debug info nor the export table, and Windows binaries don't have an equivalent
of the ELF .symtab. We need to understand why the test works to keep the
symbol out of the debug info. In the mean time, having the test fail at this
point is a better indication of the remaining problem than a build error.
Differential Revision: https://reviews.llvm.org/D43688
llvm-svn: 326130
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
Summary:
The llvm function is equivalent to this one. Where possible I tried to
replace const char* with llvm::StringRef to avoid extra strlen
computations. In most places, I was able to track the c string back to
the ConstString it was created from.
I also create a test that verifies we are able to lookup names with
unicode characters, as a bug in the llvm compiler (it accidentally used
a different hash function) meant this was not working until recently.
This also removes the unused ExportTable class.
Reviewers: aprantl, davide
Subscribers: JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D43596
llvm-svn: 325927
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
Summary:
This test launches a helper that uses the debugserver. The environment
variable sepcifying the debug server wasn't passed to this helper, thus
it was using the default one.
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D43546
llvm-svn: 325858
This test was only testing that clang produced the correct informations
for __apple accelerated tables. So, it's a clang test. Also, it
doesn't require any debugger intervention, the object file can
be analyzed statically with a dumper. Also, the input program
was highly verbose (unnecessarily).
r325850 commits a clang test instead, so it's time to retire this.
llvm-svn: 325851
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
Ensure that the test data is an array of bytes rather than a string that gets
encoded differently between Python 2 and Python 3.
Differential Revision: https://reviews.llvm.org/D43532
llvm-svn: 325835
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
The patch added an extra argument to the append_to_process_working_directory
function. I have somehow missed updating this test, and it did not show up
because the code was only run in remote mode.
llvm-svn: 325702
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
This test was accessing self.debug_info, which doesn't exist anymore. For
some reason the macOS bots are skipping this test because they think the
compiler is not clang. We'll look into this separately.
llvm-svn: 325666
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
The first issue is about the flaky test rerun logic. This was grouping
tests by subdir and passing them into walk_and_invoke in the incorrect
form. This part can be just deleted as its not needed anymore.
The second problem (which I noticed while investigating the first one)
was that the "-p" switch was not working in multiprocessing mode. This
happened because we were returning None from process_file instead of a
tuple full of empty values for tests that did not match the -p regex.
Both of these would be caught earlier if python was a more strongly
typed language. :/
llvm-svn: 325519
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 was generating long unix socket names, and the addition of a
new folder in the previous patch pushed it over the limit (although
linux has a fairly generous limit for path names, this does not apply to
unix sockets).
Modify the test to use a shorter name instead.
llvm-svn: 325340
The reason this test was disabled is no longer relevant. However, it
didn't turn into an unexpected success because of a syntax error in the
test itself. This commit fixes that and re-enables the test.
llvm-svn: 325339
Since we now can run multiple tests from the same directory at once, we
need to include the test name in the remote test directory instead.
I'm not sure if the test_number in the remote path is necessary anymore
(or even if it was ever necessary), but I choose to leave it in for now.
llvm-svn: 325334
Summary:
Due to in-tree builds, we were parallelizing the tests at the directory
level. Now that the tests are built out-of-tree, we can remove this
limitation and paralelize at file level instead.
This decreases test suite time by about 10% for me, which is not
world-shattering, but it makes the code slightly simpler and will also
allow us to merge tests which were artificially spread over multiple
folders (TestConcurrentEvents...) to work-around this limitation.
To make this work, I've also needed to include the test file name in the
build directory name, as just the test method name is not unique enough
(plenty of tests have a test method called "test" or similar).
While doing this, I've found a couple of tests that are taking waaay longer then
they ought to (TestBreakpointCaseSensitivity -- 90 seconds), which I plan to
look into in the future.
Reviewers: aprantl
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D43335
llvm-svn: 325322
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
This patch makes LLDB's clang module cache path customizable via
settings set target.clang-modules-cache-path <path> and uses it in the
LLDB testsuite to reuse the same location inside the build directory
for LLDB and clang.
Differential Revision: https://reviews.llvm.org/D43099
llvm-svn: 324775
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
The change in r324488 dropped the existing category attribute in for
instance methods. This patch corrects that.
Differential revision: https://reviews.llvm.org/D43024
llvm-svn: 324492
Inlined tests have a test function that is actually an instance method,
which requires a slightly different approach when it comes to setting
the category attribute. The attribute must be set on the actual
function, rather than on a particular instance.
llvm-svn: 324488
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
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
I have found LLDB cannot find separate debug info of Fedora /usr/bin/gdb.
It is because:
lrwxrwxrwx 1 root root 14 Jan 25 20:41 /usr/bin/gdb -> ../libexec/gdb*
-rwxr-xr-x 1 root root 10180296 Jan 25 20:41 /usr/libexec/gdb*
ls: cannot access '/usr/lib/debug/usr/bin/gdb-8.0.1-35.fc27.x86_64.debug': No such file or directory
-r--r--r-- 1 root root 29200464 Jan 25 20:41 /usr/lib/debug/usr/libexec/gdb-8.0.1-35.fc27.x86_64.debug
FYI that -8.0.1-35.fc27.x86_64.debug may look confusing, it was always just
.debug before.
Why is /usr/bin/gdb a symlink is offtopic for this bugreport, Fedora has it so
for some reasons.
It is always safest to look at the .debug file only after resolving all
symlinks on the binary file.
Differential revision: https://reviews.llvm.org/D42853
llvm-svn: 324224
I have found the lookup by build-id
(when lookup by /usr/lib/debug/path/name/exec.debug failed) does not work as
LLDB tries the build-id hex string in uppercase but Fedora uses lowercase.
xubuntu-16.10 also uses lowercase during my test:
/usr/lib/debug/.build-id/6c/61f3566329f43d03f812ae7057e9e7391b5ff6.debug
Differential revision: https://reviews.llvm.org/D42852
llvm-svn: 324222
LLDB queries Spotlight to locate .dSYM bundles based on the UUID
embedded in a binary, and because the UUID is a hash of filename and
.text section, there *will* be conflicts inside $BUILD_DIR.
This should fix the broken green dragon bots.
llvm-svn: 324019
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
We started passing the "all" target to make, which rendered the
"localall" trick in this Makefile inoperable.
I implement the strip step differently, and also reformat the Makefile.
llvm-svn: 323855
Initialize the default value of SymbolFileDWARF uuid with
the appropriately shifted DW_INVALID_OFFSET constant.
This change fixes the collision in the computation of DIE uid
(inside DIERef::GetUID) and incorrect CompileUnit lookup
(because of the misleading cu_offset value).
Test plan: make check-lldb
Differential revision: https://reviews.llvm.org/D42563
llvm-svn: 323832
Strings which contain garbage data can trigger an exception in the XUnit
plugin at the UTF-8 decode step because the decode is strict. Use a lax
mode to avoid an exception.
See: https://ci.swift.org/job/oss-lldb-incremental-osx/780
llvm-svn: 323817
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
The logic was incorrect because on windows, we need to look for
yaml2obj.EXE. I implement the search in terms of
distutils.spawn.find_executable, which should handle the platform
differences for us.
llvm-svn: 323744
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
Now the function returns `False`, and the caller can take the
appropriate action (in this case, for --executable, reporting
that the file doesn't exist).
llvm-svn: 323566
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
building method override tables for CXXMethodDecls in
DWARFASTParserClang::CompleteTypeFromDWARF.
C++ virtual method calls in LLDB expressions may fail if the override table for
the method being called is not correct as IRGen will produce references to the
wrong (or a missing) vtable entry.
This patch does not fix calls to virtual methods with covariant return types as
it mistakenly treats these as overloads, rather than overrides. This will be
addressed in a future patch.
Review: https://reviews.llvm.org/D41997
Partially fixes <rdar://problem/14205774>
llvm-svn: 323163
Due to an unfortunate difference between the open source test harness
and our internal harness, applying two @skip... decorators to this test
works in the internal build but not in the open source build.
I've tried another approach to skipping this test and tested it out with
the open source harness. Hopefully this sticks!
rdar://36417163
llvm-svn: 322756
This test frequently times out on our bots. While we're investigating
the issue, mark the test as skipped so the builds aren't impacted as
much.
rdar://36417163
llvm-svn: 322728
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
This test stresses expression evaluation support for template functions.
Currently the support is rudimentary, and running this test causes assertion
failures in clang. This test cannot be XFAIL'ed because the test harness
treats assertion failures as unexpected events. For now, the test must be
skipped.
llvm-svn: 322340
Pavel Labath