The testcase for objective-c data formatters is very big as it checks a
bunch of stuff. This is annoying when using the lit test driver, because
it prevents us from running the different cases in parallel. As a
result, it's always one of the last few tests that complete. This patch
splits the test into multiple files that share a common base class. This
way lit can run the different tests in parallel.
Differential revision: https://reviews.llvm.org/D60300
llvm-svn: 357786
When this test fails (flakes) all we get is an error message like "False
is not True". This replaces patterns like assertTrue(a == b) with
assertEqual(a, b), so we get a better error message (and hopefully a
hint as to why the test is flaky).
llvm-svn: 357747
Summary:
This patch moves the modify-python-lldb code for adding new functions to
the SBModule class into the SBModule interface file. As this is the last
class using this functionality, I also remove all support for this kind
of modifications from modify-python-lldb.py.
Reviewers: amccarth, clayborg, jingham
Subscribers: zturner, lldb-commits
Differential Revision: https://reviews.llvm.org/D60195
llvm-svn: 357680
Summary:
After https://reviews.llvm.org/D59828 and https://reviews.llvm.org/D59849,
I believe the problems with these tests hanging have been solved.
I tried enabling all of them on my machine, and got two failures:
- One of them was spawning a child process that lives for 5 seconds, waited
for 5 seconds to attach to the child, and failed because the child wasn't
there.
- The other one was a legit failure because shell expansion of arguments doesn't
work on Linux.
This tests enables all lldb-vscode tests on Linux except for "launch process
with shell expansion of args" (which doesn't work), and fixes the other broken
test by reducing the time it waits before attaching to its child process.
Reviewers: zturner, clayborg
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D60153
llvm-svn: 357633
Allow partial UUID matching in Minidump core file plug-in
Breakpad had bugs in earlier versions where it would take a 20 byte ELF build ID and put it into the minidump file as a 16 byte PDB70 UUID with an age of zero. This would make it impossible to do postmortem debugging with one of these older minidump files.
This fix allows partial matching of UUIDs. To do this we first try and match with the full UUID value, and then fall back to removing the original directory path from the module specification and we remove the UUID requirement, and then manually do the matching ourselves. This allows scripts to find symbols files using a symbol server, place them all in a directory, use the "setting set target.exec-search-paths" setting to specify the directory, and then load the core file. The Target::GetSharedModule() can then find the correct file without doing any other matching and load it.
Tests were added to cover a partial UUID match where the breakpad file has a 16 byte UUID and the actual file on disk has a 20 byte UUID, both where the first 16 bytes match, and don't match.
Differential Revision: https://reviews.llvm.org/D60001
llvm-svn: 357603
Summary:
Instead of modifying the swig-generated code, just add the appropriate
methods to the interface files in order to get the swig to do the
generation for us.
This is a straight-forward move from the python script to the interface
files. The single class which has nontrivial handling in the script
(SBModule) has been left for a separate patch.
For the cases where I did not find any tests exercising the
iteration/length methods (i.e., no tests failed after I stopped emitting
them), I tried to add basic tests for that functionality.
Reviewers: zturner, jingham, amccarth
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D60119
llvm-svn: 357572
See discussion in https://reviews.llvm.org/D60001.
Revert Clean up windows build bot.
This reverts r357504 (git commit 380c2420ecb0c3e809b04f385d37b89800df1ecf)
Revert Fix buildbot where paths were not matching up.
This reverts r357491 (git commit 5050586860140b55a0cc68c77dd1438f44a23ca5)
Revert Allow partial UUID matching in Minidump core file plug-in
This reverts r357482 (git commit 838bba9c34bf1e5500c2e100327bc764afc8d367)
llvm-svn: 357534
Breakpad had bugs in earlier versions where it would take a 20 byte ELF build ID and put it into the minidump file as a 16 byte PDB70 UUID with an age of zero. This would make it impossible to do postmortem debugging with one of these older minidump files.
This fix allows partial matching of UUIDs. To do this we first try and match with the full UUID value, and then fall back to removing the original directory path from the module specification and we remove the UUID requirement, and then manually do the matching ourselves. This allows scripts to find symbols files using a symbol server, place them all in a directory, use the "setting set target.exec-search-paths" setting to specify the directory, and then load the core file. The Target::GetSharedModule() can then find the correct file without doing any other matching and load it.
Tests were added to cover a partial UUID match where the breakpad file has a 16 byte UUID and the actual file on disk has a 20 byte UUID, both where the first 16 bytes match, and don't match.
Differential Revision: https://reviews.llvm.org/D60001
llvm-svn: 357482
I'm not sure why this surfaced at this particular point, but
TestCommandScriptImmediateOutput (a pexpect test) had a synchronization
issue, where the (lldb) promts it was expecting were getting out of
sync. This happened for two reasons:
- it did not expect the initial (lldb) prompt we print at startup
- launchArgs() returned None, which resulted in an extra "target create
None" command being issued to lldb (and an extra unhandled prompt
being printed).
Resolving these two issues seems to fix (or at least, improve) the test.
llvm-svn: 357459
The test was hitting llvm_unreachable in
Platform::GetSoftwareBreakpointTrapOpcode because it could not figure
out the architecture of the process. Since that is not the purpose of
the test, I change the test to use an explicit
CreateTargetWithFileAndTargetTriple command to specify it.
llvm-svn: 357456
While reviewing D56233 it became clear to me that this test can be
simplified. There's no need for a start-stop cycle in the inferior -- we
can start fiddling with its registers as soon as it is launched.
llvm-svn: 357451
Summary:
This change prevents the lldb-vscode test harness from hanging up waiting for
new messages when the lldb-vscode subprocess crashes.
Now, when an EOF from the subprocess pipe is detected we enqueue a `None` packet
in the received packets list. Then, during the message processing loop, we can
use this `None` packet to tell apart the case where lldb-vscode has terminated
unexpectedly from the normal situation where no pending messages means blocking
and waiting for more data.
I believe this should be enough to fix the issues with these tests hanging on
multiple platforms. Once this lands, I'll prepare and test a separate change
removing the @skipIfLinux annotations.
Reviewers: clayborg, zturner
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D59849
llvm-svn: 357426
Summary:
In case of a breakpoint site overlapping with the destination address,
the WriteMemory method reported an incorrect memory size.
Instead of returning the right amount of bytes written, it falls through
the scope and returned 0.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Reviewers: jasonmolenda, friss, jingham
Subscribers: JDevlieghere, davide, lldb-commits, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D60022
llvm-svn: 357420
Include support for NetBSD core dumps from evbarm/aarch64 system,
and matching test cases for them.
Based on earlier work by Kamil Rytarowski.
Differential Revision: https://reviews.llvm.org/D60034
llvm-svn: 357399
It was making a list of a certain size but not always filling in that
many elements, which would lead to a crash iterating over the list.
Differential Revision: https://reviews.llvm.org/D59913
llvm-svn: 357207
The changes were reverted due to ubsan errors (unaligned accesses). Here
I fix those errors by first copying the data into aligned storage.
Besides fixing alignment issues, this also fixes reading of minidump
strings on big-endian systems.
llvm-svn: 356896
This reverts the following two commits:
Revert "Extend r356573 (minidump UUID handling) to cover elf build-ids too"
Revert "Fix UUID decoding from minidump files"
Greg's original commit broke the sanitizer bot which has been red for
several days now.
http://green.lab.llvm.org/green/view/LLDB/job/lldb-sanitized/
llvm-svn: 356806
Breakpad (but not crashpad) will insert an empty (all-zero) build-id
record for modules which do not have a build-id. This tells lldb to
treat such records as empty/invalid uuids.
llvm-svn: 356751
This patch fixes:
UUIDs now don't include the age field from a PDB70 when the age is zero. Prior to this they would incorrectly contain the zero age which stopped us from being able to match up the UUID with real files.
UUIDs for Apple targets get the first 32 bit value and next two 16 bit values swapped. Breakpad incorrectly swaps these values when it creates darwin minidump files, so this must be undone so we can match up symbol files with the minidump modules.
UUIDs that are all zeroes are treated as invalid UUIDs. Breakpad will always save out a UUID, even if one wasn't available. This caused all files that have UUID values of zero to be uniqued to the first module that had a zero UUID. We now don't fill in the UUID if it is all zeroes.
Added tests for PDB70 and ELF build ID based CvRecords.
Differential Revision: https://reviews.llvm.org/D59433
llvm-svn: 356573
Python 3 default encoding is utf-8, so taking random bytes and
interpreting them as a string might result in invalid unicode sequences.
As the only thing we care about here is that the formatter shows the
elements of the underyling array, relax the string matching (this is
good enough as all the elements are distinct so they resolve to different
strings).
llvm-svn: 356096
Given this was under trace, it can just be removed. If somebody
ever needs to debug this testcase again and print the data, they
can add a new statement.
llvm-svn: 355999
Summary:
This patch is the MVP version of importing the std module into the expression parser to improve C++ debugging.
What happens in this patch is that we inject a `@import std` into our expression source code. We also
modify our internal Clang instance for parsing this expression to work with modules and debug info
at the same time (which is the main change in terms of LOC). We implicitly build the `std` module on the first use. The
C++ include paths for building are extracted from the debug info, which means that this currently only
works if the program is compiled with `-glldb -fmodules` and uses the std module. The C include paths
are currently specified by LLDB.
I enabled the tests currently only for libc++ and Linux because I could test this locally. I'll enable the tests
for other platforms once this has landed and doesn't break any bots (and I implemented the platform-specific
C include paths for them).
With this patch we can now:
* Build a libc++ as a module and import it into the expression parser.
* Read from the module while also referencing declarations from the debug info. E.g. `std::abs(local_variable)`.
What doesn't work (yet):
* Merging debug info and C++ module declarations. E.g. `std::vector<CustomClass>` doesn't work.
* Pretty much anything that involves the ASTImporter and templated code. As the ASTImporter is used for saving the result declaration, this means that we can't
call yet any function that returns a non-trivial type.
* Use libstdc++ for this, as it requires multiple include paths and Clang only emits one include path per module. Also libstdc++ doesn't support Clang modules without patches.
Reviewers: aprantl, jingham, shafik, friss, davide, serge-sans-paille
Reviewed By: aprantl
Subscribers: labath, mgorny, abidh, jdoerfert, lldb-commits
Tags: #c_modules_in_lldb, #lldb
Differential Revision: https://reviews.llvm.org/D58125
llvm-svn: 355939
Summary:
This patch marks the inline namespaces from DWARF as inline and also ensures that looking
up declarations now follows the lookup rules for inline namespaces.
Reviewers: aprantl, shafik, serge-sans-paille
Reviewed By: aprantl
Subscribers: eraman, jdoerfert, lldb-commits
Tags: #c_modules_in_lldb, #lldb
Differential Revision: https://reviews.llvm.org/D59198
llvm-svn: 355897
There was a crash that would happen if an IDE would ask for a child of a shared pointer via any SB API call that ends up calling StackFrame::GetValueForVariableExpressionPath(). The previous code expects an error to be set describing why the synthetic child of a type was not able to be found, but we have some synthetic child providers that weren't setting the error and returning an empty value object shared pointer. This fixes that to ensure we don't lose our debug session by crashing, fully tests GetValueForVariableExpressionPath functionality, and ensures we don't crash on GetValueForVariableExpressionPath() in the future.
Differential Revision: https://reviews.llvm.org/D59200
llvm-svn: 355850
