This adds a wrapper around dotest, similar to llvm-lit in llvm. The
wrapper is created in the binary directory, next to LLDB and allows you
to invoke dotest without having to pass any of the configuration
arguments yourself. I think this could also be useful for re-running a
particular test case when it fails, as an alternative to "Command
Invoked".
The motivation for this is that I'd like to replace the driver part of
dotest with lit. As a first step, I'd like to have lit invoke dotest,
which would just run the complete test suite, completely identical to
what the CMake target does today. Once this is in place, we can have lit
run dotest for the different test directories, and ultimately once per
python file. Along the way we can strip out driver functionality from
dotest where appropriate.
https://reviews.llvm.org/D44002
llvm-svn: 326687
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
This patch removes the HashString function from StringExtraces and
replaces its uses with calls to djbHash from DJB.h.
This change is *almost* NFC. While the algorithm is identical, the
djbHash implementation in StringExtras used 0 as its default seed while
the implementation in DJB uses 5381. The latter has been shown to result
in less collisions and improved avalanching and is used by the DWARF
accelerator tables.
Because some test were implicitly relying on the hash order, I've
reverted to using zero as a seed for the following two files:
lld/include/lld/Core/SymbolTable.h
llvm/lib/Support/StringMap.cpp
Differential revision: https://reviews.llvm.org/D43615
llvm-svn: 326091
It looks like some of our tests depend on the ordering of hashed values.
I'm reverting my changes while I try to reproduce and fix this locally.
Failing builds:
lab.llvm.org:8011/builders/lld-x86_64-darwin13/builds/18388
lab.llvm.org:8011/builders/clang-cmake-x86_64-sde-avx512-linux/builds/6743
lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/15607
llvm-svn: 326082
This removes the HashString function from StringExtraces and replaces
its uses with calls to djbHash from DJB.h
This is *almost* NFC. While the algorithm is identical, the djbHash
implementation in StringExtras used 0 as its seed while the
implementation in DJB uses 5381. The latter has been shown to result in
less collisions and improved avalanching.
https://reviews.llvm.org/D43615
(cherry picked from commit 77f7f965bc9499a9ae768a296ca5a1f7347d1d2c)
llvm-svn: 326081
The lldb-server unit tests don't test the right thing when the debug
server in use is copied from somewhere else. This can lead to spurious
test failures.
Disable these unit tests when an external debug server is in use.
Fixes llvm.org/PR36494.
llvm-svn: 326001
Removing the template arguments and most of the mutating methods from
CleanUp makes it easier to understand and reuse.
In its present state, CleanUp would be too cumbersome to adapt to cases
where multiple objects need to be released. Take for example this change
in swift-lldb:
https://github.com/apple/swift-lldb/pull/334/files#diff-6f474df750f75c8ba675f2a8408a5629R219
This change is simple to express with the new CleanUp, but not so simple
with the old version.
Differential Revision: https://reviews.llvm.org/D43662
llvm-svn: 325964
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 is consistently reporting unexpected pass for me, and the
expectedFailure decorator was removed from the legacy test in r310626.
Apply the same change to the lit version of this test.
Will investigate further if this fails once the new buildbot is running
tests.
llvm.org/pr17807
llvm-svn: 325856
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
Jonas Devlieghere