Add a function to flatten the nested aggregate type
Differential Revision: https://reviews.llvm.org/D62702
Patch by Wanyi Ye <kusmour@gmail.com>
llvm-svn: 362543
This fixes an unintended regression introduced by
https://reviews.llvm.org/D61451 by making sure the Objective-C runtime
is also tried when the "correct" language runtime failed to return an
object description.
rdar://problem/50791055
Differential Revision: https://reviews.llvm.org/D62015
llvm-svn: 360929
Summary:
I don't think there's a good reason for this behavior to be considered
ObjC-specific. We can generalize this.
Differential Revision: https://reviews.llvm.org/D61776
llvm-svn: 360741
Replace checked-in minidumps with their yaml forms now that yaml2obj
supports the ThreadList stream. I delete the test_modules_in_mini_dump
test altogether as this functionality is covered more systematically in
TestMinidumpUUID.py.
llvm-svn: 360655
logging when the testsuite is run with trace mode enabled are leaving
the logging enabled after the tests have finished. That state
isn't cleared in a --no-multiprocess testsuite run.
llvm-svn: 360480
This can cause us to return paths to files on the local filesystem even
if we don't end up using that file (for instance because the file is not
a real module).
llvm-svn: 360432
While this fixed the windows bot failures, it also broke all other bots.
Upon closer inspection, it turns out that the windows bots were "broken"
because two tests were unexpectedly passing -- i.e., the original patch
(r360375) actually improved our stepping support on windows.
So instead, I remove the relevant XFAILs.
This reverts commit r360397.
llvm-svn: 360407
Currently when we single step over a source line, we run and stop at every branch in the source line range. We can reduce the number of times we stop when stepping over by figuring out if any of these branches are function calls, and if so, ignore these branches. Since we are stepping over we can safely ignore these calls since they will return to the next instruction. Currently the step logic would stop at those branches (1st stop), single step into the branch (2nd stop), and then set a breakpoint at the return address (3rd stop), and then continue.
Differential Revision: https://reviews.llvm.org/D58678
llvm-svn: 360375
The test is failing sometimes because the debugger is failing to attach for lack of permissions. The fix is to call lldb_enable_attach inside the inferior main function
llvm-svn: 360371
This particular test fails once every so many runs on GreenDragon. Given
that the randomness in the inferior isn't critical to the test, I
removed it in the hopes that it is the cause of the flakiness.
llvm-svn: 359992
Ran clang-format on the added test file and use the new StringRef
comparison over the temporary ConstStrings. Also aligned the
end of one of the code string literals.
llvm-svn: 359931
This patch makes `re` an alias for `register`. Currently `re<TAB>` gives
you the choice between `register` and `reproducer`. Given that you use
`register` a lot more often, it should win for the common substring.
Differential revision: https://reviews.llvm.org/D61469
llvm-svn: 359927
Summary:
In an Objective-C context a local variable and namespace can cause an ambiguous name lookup when used in an expression. The solution involves mimicking the existing C++ solution which is to add local using declarations for local variables. This causes a different type of lookup to be used which eliminates the namespace during acceptable results filtering.
Differential Revision: https://reviews.llvm.org/D59960
llvm-svn: 359921
The part which checks whether vla_expr shows up in the variable list
does not pass on non-darwin platforms. Add the appropriate decorator.
llvm-svn: 359867
by respecting the "artificial" attribute on variables. Function
arguments that are artificial and useful to end-users are being
whitelisted by the language runtime.
<rdar://problem/45322477>
Differential Revision: https://reviews.llvm.org/D61451
llvm-svn: 359841
Two tests cannot share the same name, because they will generate an
identical trace file. When that happens, this can lead to a race
condition where dotest fails when trying to move both files into the
trace directory, because the file has already been moved. Additionally,
the trace will have been overwritten by the test that finishes last.
llvm-svn: 359807
Summary:
In r259902, LLDB started injecting all the locals in every expression
evaluation. This fixed a bunch of issues, but also caused others, mostly
performance regressions on some codebases. The regressions were bad
enough that we added a setting in r274783 to control the behavior and
we have been shipping with the setting off to avoid the perf regressions.
This patch changes the logic injecting the local variables to only inject
the ones present in the expression typed by the user. The approach is
fairly simple and just scans the typed expression for every local name.
Hopefully this gives us the best of both world as it just realizes the
types of the variables really used by the expression.
Landing this requires the 2 other issues I pointed out today to be addressed
but I wanted to gather comments right away.
Original patch by Frédéric Riss!
Reviewers: jingham, clayborg, friss, shafik
Reviewed By: jingham, clayborg
Subscribers: teemperor, labath, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D46551
llvm-svn: 359773
This test is flaky on GreenDragon. Since it was a pexpect test and
straightforward enough to convert, I went ahead and converted it to a
lit test.
Differential revision: https://reviews.llvm.org/D61414
llvm-svn: 359751
Summary:
This will fix a bug where during expression parsing we are not setting a CXXRecordDecl to not be passed in registers and the resulting code generation is wrong.
The DWARF attribute DW_CC_pass_by_reference tells us that we should not be passing in registers i.e. RAA_Indirect.
This change depends this clang change which fixes the fact that the ASTImporter does not copy RecordDeclBits for CXXRecordDecl: https://reviews.llvm.org/D61140
Differential Revision: https://reviews.llvm.org/D61146
llvm-svn: 359732
After multiple attempts from both Fred and Adrian, this variant of the
test is still flaky on GreenDragon. This commit disables it while we
continue investigate.
llvm-svn: 359724
Summary:
This patch is a follow-up for D58125. It implements the manual instantiation and merging of 'std' templates like
`std::vector` and `std::shared_ptr` with information from the debug info AST. This (finally) allows using these classes
in the expression evaluator like every other class (i.e. things like `vec.size()` and shared_ptr debugging now works, yay!).
The main logic is the `CxxModuleHandler` which intercept the ASTImporter import process and replaces any `std` decls
by decls from the C++ module. The decls from the C++ module are "imported" by just deserializing them directly in
the expression evaluation context. This is mostly because we don't want to rely on the ASTImporter to correctly import
these declarations, but in the future we should also move to the ASTImporter for that.
This patch doesn't contain the automatic desugaring for result variables. This means that if you call for example
`size` of `std::vector` you maybe get some very verbose typedef'd type as the variable type, e.g.
`std::vector<int, std::allocator<int>>::value_type`.
This is not only unreadable, it also means that our ASTImporter has to import all these types and associated
decls into the persisent variable context. This currently usually leads to some assertion getting triggered
in Clang when the ASTImporter either makes a mistake during importing or our debug info AST is inconsitent.
The current workaround I use in the tests is to just cast the result to it's actual type (e.g. `size_t` or `int`) to prevent
the ASTImporter from having to handle all these complicated decls.
The automatic desugaring will be a future patch because I'm not happy yet with the current code for that and because
I anticipate that this will be a controversial patch.
Reviewers: aprantl, shafik, jingham, martong, serge-sans-paille
Reviewed By: martong
Subscribers: balazske, rnkovacs, mgorny, mgrang, abidh, jdoerfert, lldb-commits
Tags: #c_modules_in_lldb, #lldb
Differential Revision: https://reviews.llvm.org/D59537
llvm-svn: 359538
Summary:
Dump more information about "access violation" and "in page error" exceptions to
description. Description now contains data about read/write violation type and
actual address as described at
https://docs.microsoft.com/en-us/windows/desktop/api/winnt/ns-winnt-_exception_record
Reviewers: asmith, stella.stamenova
Reviewed By: stella.stamenova
Subscribers: teemperor, amccarth, abidh, lldb-commits, aleksandr.urakov
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D60519
llvm-svn: 359420
Summary:
When we encounter a templated function in the debug information, we
were creating an AST that looked like this:
FunctionTemplateDecl 0x12980ab90 <<invalid sloc>> <invalid sloc> foo<int>
|-TemplateTypeParmDecl 0x12980aad0 <<invalid sloc>> <invalid sloc> class depth 0 index 0 T
|-FunctionDecl 0x12980aa30 <<invalid sloc>> <invalid sloc> foo<int> 'int (int)' extern
| |-TemplateArgument type 'int'
| `-ParmVarDecl 0x12980a998 <<invalid sloc>> <invalid sloc> t1 'int'
`-FunctionDecl 0x12980aa30 <<invalid sloc>> <invalid sloc> foo<int> 'int (int)' extern
|-TemplateArgument type 'int'
`-ParmVarDecl 0x12980a998 <<invalid sloc>> <invalid sloc> t1 'int'
Note that the FunctionTemplateDecl has 2 children which are identical (as
in have the same address). This is not what Clang is doing:
FunctionTemplateDecl 0x7f89d206c6f8 </tmp/template.cpp:1:1, line:4:1> line:2:5 foo
|-TemplateTypeParmDecl 0x7f89d206c4a8 <line:1:10, col:19> col:19 referenced typename depth 0 index 0 T
|-FunctionDecl 0x7f89d206c660 <line:2:1, line:4:1> line:2:5 foo 'int (T)'
| `-ParmVarDecl 0x7f89d206c570 <col:9, col:11> col:11 t1 'T'
`-FunctionDecl 0x7f89d206cb60 <line:2:1, line:4:1> line:2:5 used foo 'int (int)'
|-TemplateArgument type 'int'
`-ParmVarDecl 0x7f89d206ca68 <col:9, col:11> col:11 t1 'int':'int'
The 2 chidlren are different and actually repesent different things: the first
one is the unspecialized version and the second one is specialized. (Just looking
at the names shows another major difference which is that we create the parent
with a name of "foo<int>" when it should be just "foo".)
The fact that we have those 2 identical children confuses the ClangImporter
and generates an infinite recursion (reported in https://llvm.org/pr41473).
We cannot create the unspecialized version as the debug information doesn't
contain a mapping from the template parameters to their use in the prototype.
This patch just creates 2 different FunctionDecls for those 2 children of the
FunctionTemplateDecl. This avoids the infinite recursion and allows us to
call functions. As the XFAILs in the added test show, we've still got issues
in our handling of templates. I believe they are mostly centered on the fact
that we create do not register "foo" as a template, but "foo<int>". This is
a bigger change that will need changes to the debug information generation.
I believe this change makes sense on its own.
Reviewers: shafik, clayborg, jingham
Subscribers: aprantl, javed.absar, kristof.beyls, lldb-commits
Differential Revision: https://reviews.llvm.org/D61044
llvm-svn: 359140
Summary:
This previous fix 5469bda296 did not have a test since we did not have a reproducer.
This is related to how formatters deal with pointers and references. The added tests both the new behavior and covers the previous bug fix as well.
Differential Revision: https://reviews.llvm.org/D60588
llvm-svn: 359118
Summary:
Instead of checking in raw minidump binaries, check in their yaml form,
and call yaml2obj in the test.
Reviewers: clayborg
Subscribers: javed.absar, lldb-commits
Differential Revision: https://reviews.llvm.org/D60948
llvm-svn: 358957
Summary:
The test was failing occasionally (1% of runs or so), because of
unpredictable timings between the two threads spawned by the test. If
the second thread hit the breakpoint right as we were stepping out of
the function on the first thread, we would still be stuck at the inner
frame when the process stopped.
This would cause errors like:
File "/home/worker/lldb-x86_64-debian/lldb-x86_64-debian/llvm/tools/lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/step/TestVSCode_step.py", line 67, in test_step
self.assertEqual(x1, x3, 'verify step out variable')
AssertionError: 2 != 1 : verify step out variable
AFAICT, lldb-vscode is doing the right thing here, and the problem is
that the test is not taking this sequence of events into account. Since
the test is about testing stepping, it does not seem necessary to have
threads in the inferior at all, so I just rewrite the test to execute
the code we're supposed to step through directly on the main thread.
Reviewers: clayborg, jgorbe
Subscribers: jfb, lldb-commits
Differential Revision: https://reviews.llvm.org/D60608
llvm-svn: 358847
As I was waiting for the test suite to complete at 99% I noticed this
test taking quite a bit of time. Since it's easy to split I just went
ahead and did so.
llvm-svn: 358792
D59433 and D60501 changed the way UUIDs are computed from minidump
files. This was done to synchronize the U(G)UID representation with the
native tools of given platforms, but it created a mismatch between
minidumps and breakpad files.
This updates the breakpad algorithm to match the one found in minidumps,
and also adds a couple of tests which should fail if these two ever get
out of sync. Incidentally, this means that the module id in the breakpad
files is almost identical to our notion of UUIDs, so the computation
algorithm can be somewhat simplified.
llvm-svn: 358500
Summary:
https://reviews.llvm.org/D51633 added error handling in the ASTImporter.cpp which uncovered an underlying bug in which we used the wrong name when handling naming conflicts. This could cause a segmentation fault when attempting to cast an int to an enum during expression parsing.
This test should pass once https://reviews.llvm.org/D59665 is committed.
Differential Revision: https://reviews.llvm.org/D59667
llvm-svn: 358462
This test contained an incredibly complicated inferior, but in reality,
all it was testing was that we can backtrace up to main and see main's
arguments.
However, the way this was implemented (setting a breakpoint on a
separate thread) meant that each time the test would run, it would stop
in a different location on the main thread. Most of the time this
location would be deep in some libc function, which meant that the
success of this test depended on our ability to backtrace out of a
random function of the c library that the user happens to have
installed.
This makes the test unpredictable. Backtracing out of a libc function is
an important functionality, but this is not the way to test it. Often it
is not even our fault that we cannot backtrace out because the C library
contains a lot of assembly routines that may not have correct unwind
info associated with them.
For this reason the test has accumulated numerous @expectedFail/Flaky
decorators. In this patch, I replace the inferior with one that does not
depend on libc functions. Instead I create a couple of stack frames of
user code, and have the test verify that. I also simplify the test by
using lldbutil.run_to_source_breakpoint.
llvm-svn: 358266
This converts the CommandScriptImmediateOutput test from a python test
using pexpect to a lit test.
Differential revision: https://reviews.llvm.org/D60566
llvm-svn: 358180
Summary:
D59433 added code to swap bytes UUIDs coming from minidump files, but
only enabled it for apple platforms. Based on my research, I believe
this is the correct thing to do for windows as well, as the natural way
of printing U(G)UIDs on this platforms is to print the first three
components as (4 or 2)-byte integers printed in natural (big-endian)
order. This makes the UUID string coming out of lldb match the strings
produced by other windows tools.
The decision to byte-swap the age field is somewhat arbitrary, because
the age field is usually printed separately from the file GUID (and
often in decimal). However, for our purposes (telling whether two files
are identical), including it in the UUID is correct, and printing it in
big-endian makes it easier to recognize the age value.
This also makes the UUIDs generated here (almost) match up with the
UUIDs computed for breakpad symbol files
(BreakpadRecords.cpp:parseModuleId), which already implemented the
byte-swapping. The "almost" is here because ObjectFileBreakpad does not
swap the age field, but I'll fix that in a follow-up.
There is no UUID support in ObjectFileCOFF at the moment, but ideally
the algorithms used here and in ObjectFileCOFF should be in sync so that
object file matching works correctly.
Reviewers: clayborg, amccarth, markmentovai, asmith
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D60501
llvm-svn: 358169
TestObjCMethods2.py was the third-longest running test on Darwin. By
splitting it up, lit can exploit parallelism to reduce the total wall
clock time.
llvm-svn: 358088
Add a flag to control whether the ModulesDidLoad notification is
called when a module is added. If the notifications are disabled,
the caller must call ModulesDidLoad after adding all the new modules,
but postponing this notification until they're all batched up can
allow for better efficiency than notifying one-by-one.
Change the name of the ModuleList notifier functions that a subclass
can implement to start with 'Notify' to make it clear what they are.
Add a NotifyModulesRemoved.
Add header documentation for the changed/updated methods.
Added defaulted-value 'notify' argument to ModuleList Append,
AppendIfNeeded, and Remove because callers working with a local
ModuleList don't have an obvious idea of what notify means in this
context. When the ModuleList is a part of the Target class, the
notify behavior matters.
DynamicLoaderDarwin has been updated so that libraries being
added/removed are correctly batched up before notifications are
sent. Added the TestModuleLoadedNotifys.py test to run on
Darwin to test this.
<rdar://problem/48293064>
Differential Revision: https://reviews.llvm.org/D60172
llvm-svn: 357955
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 380c2420ec)
Revert Fix buildbot where paths were not matching up.
This reverts r357491 (git commit 5050586860)
Revert Allow partial UUID matching in Minidump core file plug-in
This reverts r357482 (git commit 838bba9c34)
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
Fix 2lwp_process_SIGSEGV NetBSD core test to terminate inside regular
function rather than libc call, in order to get reproducible backtrace
on different platforms.
Differential Revision: https://reviews.llvm.org/D59177
llvm-svn: 355786
Adjust the XFAIL-ing tests to match consistent results from buildbot.
I'm going to work on differences between them and my local results
following this.
llvm-svn: 355774
The code commited in r355764 didn't do what I want as I typed GetThreadID
instead of GetQueueID. This commit contains a (hopefully) better version
of the workaround.
llvm-svn: 355766
This is not a fix, but if I understand enough of the issue, it should
bail out early of the test when in a situation that would result in
a failure down the road.
llvm-svn: 355764
Fix the NetBSD core test not to verify libc function names in backtrace.
This obviously requires the same libc.so as originally used to produce
the core file, and so it is going to fail everywhere except on my
system.
llvm-svn: 355747
Improve the support for processing NetBSD cores. Fix reading process
identifier, thread information and associating the terminating signal
with the correct thread.
Includes test cases for single-threaded program receiving SIGSEGV,
and two dual-threaded programs: one where thread receives the signal,
and the other one when the whole process is signalled.
Differential Revision: https://reviews.llvm.org/D32149
llvm-svn: 355736
The last round of logging taught us that when the test fails, lldb
is indeed aware of the thread it's failing to associate to a given
queue. Add more logging to try to figure out why the thread and the
queue do not appear related to the Queue APIs.
llvm-svn: 355706
I committed an implementation of GetClangResourceDir on windows but
forgot to update this test. I merged the tests like I intended to, but I
realized that the test was actually failing. After looking into it, it
appears that FileSystem::Resolve was taking the path and setting
the FileSpec's Directory to "/path/to/lldb/lib/clang/" and the File to
"9.0.0" which isn't what we want. So I removed the resolve line from
DefaultComputeClangResourceDir.
llvm-svn: 355648
Core files need to know the size of the PRSTATUS header so that we can grab the register values that follow it. The code that figure out this size was using a hard coded list of architecture cores instead of relying on 32 or 64 bit for most cores.
The fix here fixes core files for 32 bit ARM. Prior to this the PRSTATUS header size was being returned as zero and the register values were being taken from the first bytes of the PRSTATUS struct (signo, etc).
Differential Revision: https://reviews.llvm.org/D58985
llvm-svn: 355526
Summary: This tests a fix in the ASTImpoter.cpp to ensure that we import built-in correctly,
see differential: https://reviews.llvm.org/D58743
Once this change is merged this test should pass and should catch regressions in this feature.
Differential Revision: https://reviews.llvm.org/D58790
llvm-svn: 355525
Pass appropriate -L and -Wl,-rpath flags pointing out to the LLVM
library directory on NetBSD. This is necessary since clang on NetBSD
requires libc++ but it is not installed as part of the system
by default. For the purpose of running buildbot, we want LLDB to use
just-built libc++.
Differential Revision: https://reviews.llvm.org/D58630
llvm-svn: 355502
Summary:
I'm doing this because I plan on implementing `ComputeClangResourceDirectory`
on windows so that `GetClangResourceDir` will work. Additionally, I made
test_paths make sure that the directory member of the returned FileSpec is not
none. This will fail on windows since `ComputeClangResourceDirectory` isn't
implemented yet.
Differential Revision: https://reviews.llvm.org/D58748
llvm-svn: 355463
Add a convenience 'expectedFailureNetBSD' decorator and mark all tests
currently failing on NetBSD with it. Also skip a few tests that hang
the test suite. This should establish a baseline for the test suite
and get us closer to enabling tests on buildbot. This will help us
catch regressions while we still have a lot of work to do to get tests
working.
It seems that there are also some flaky tests. I am going to address
them later on.
Differential Revision: https://reviews.llvm.org/D58527
llvm-svn: 355320
Remove the code forcing -stdlib=libstdc++ on NetBSD in getBuildFlags()
method. NetBSD uses libc++ everywhere else, and using libstdc++ here
causes lang/cpp/dynamic-value to fail to build.
Differential Revision: https://reviews.llvm.org/D58871
llvm-svn: 355273
Traditionally objc had two entry points, objc_msgSend for scalar
return methods, and objc_msgSend_stret for struct return convention
methods. But on arm64 the second was not needed (since arm64 doesn't
use an argument register for the struct return pointer) so it was removed.
The code that dispatches to the objc object checker when it sees some
flavor of objc_msgSend was not aware of this change so was sending the
wrong arguments to the checker.
<rdar://problem/48315890>
Differential Revision: https://reviews.llvm.org/D58699
llvm-svn: 355026
It turns out these tests actually succeed, if one has a clang with
address sanitizer support enabled (i.e., has enabled the compiler-rt
project). I guess none of the linux lldb devs have done that until now.
llvm-svn: 354976
The deserializer was not handling this case. For now we just
accept the absent option, and set it to the breakpoint default.
This will be more important if/when I figure out how to serialize
the options set on breakpont locations.
<rdar://problem/48322664>
llvm-svn: 354702
Fix the load_* using test Makefiles not to link -ldl on NetBSD.
There is no such a library on NetBSD, and dlopen() is available
without a library. Quoting the manpage:
(These functions are not in a library. They are included in every
dynamically linked program automatically.)
To resolve this portably, introduce a new USE_LIBDL option. If it set
to 1, Makefile.rules automatically appends -ldl on platforms needing it.
Differential Revision: https://reviews.llvm.org/D58517
llvm-svn: 354617
Getting failure when building in a directory which is symlinked elsewhere:
Failing Tests (1):
lldb-Suite :: functionalities/breakpoint/comp_dir_symlink/TestCompDirSymLink.py
lldb-Suite :: source-manager/TestSourceManager.py
For TestCompDirSymLink:
------------------------------------------------------------------------------
runCmd: file .../lldb-test-build.noindex/functionalities/breakpoint/comp_dir_symlink/TestCompDirSymLink.test_symlink_paths_set_procselfcwd_dwarf/CompDirSymLink
output: Current executable set to '.../lldb-test-build.noindex/functionalities/breakpoint/comp_dir_symlink/TestCompDirSymLink.test_symlink_paths_set_procselfcwd_dwarf/CompDirSymLink' (x86_64).
runCmd: settings set plugin.symbol-file.dwarf.comp-dir-symlink-paths /proc/self/cwd
output: None
runCmd: breakpoint set -f ".../lldb-test-build.noindex/functionalities/breakpoint/comp_dir_symlink/TestCompDirSymLink.test_symlink_paths_set_procselfcwd_dwarf/relative.cpp" -l 11
output: Breakpoint 1: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.
It is because /proc/self/cwd (used above for plugin.symbol-file.dwarf.comp-dir-symlink-paths) points to an already resolved directory:
(cd /tmp;mkdir real;ln -s real symlink;cd symlink;ls -l /proc/self/cwd)
lrwxrwxrwx 1 jkratoch jkratoch 0 Feb 20 19:55 /proc/self/cwd -> /tmp/real/
------------------------------------------------------------------------------
For TestSourceManager the resolving is done by 'make -C' as found by Pavel Labath.
Differential Revision: https://reviews.llvm.org/D58465
llvm-svn: 354556
encode/decode the data before sending it over the socket. Since (AFAICT)
the vscode protocol (unlike the gdb-remote one) is fully textual, using
the utf8 codec here is appropriate.
llvm-svn: 354308
Summary:
The compilation of the TestDataFormatterLibcxxListLoop.py currently fails with this error:
```
functionalities/data-formatter/data-formatter-stl/libcxx/list/loop/main.cpp:19:24: error: no member named '__value_' in 'std::__1::__list_node_base<int, void *>'
assert(third_elem->__value_ == 3);
~~~~~~~~~~ ^
```
It seems the internal structure of list has changed with the 3.8 release. This patch makes the test compile with the current libc++ and with the previous libc++.
Reviewers: shafik, zturner, labath
Reviewed By: labath
Subscribers: christof, jdoerfert, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D58273
llvm-svn: 354202
test/lang/cpp/class-template-parameter-pack/TestClassTemplateParameterPack.py
It fails on Mac OS; apparently a VarDecl 'void *&C' is implicitly
declared there, making the class template name C ambiguous.
llvm-svn: 354185
This applies the same fix that was done in r354106 to the lldb-server
test: bitcasting the string to a bytes object before sending it over a
socket. Since the gdb-remote protocol occasionally contains binary data,
and it does not assign any particular encoding to them, this is the
right thing to do here.
llvm-svn: 354114
Summary:
This patch finishes the python3-ification of the lldb-server test suite.
It reverts the partial attempt in r352709 to encode/decode the string
via utf8 before writing to the socket. This wasn't enough because the
gdb-remote protocol can sometimes (but not very often) carry binary
data, and the utf8 codec chokes on that. Instead I add utility functions
to the "seven" module for performing "identity" transformations on the
byte data. This basically drills back the hole in the python type system
that the string/bytes distinction was supposed to plug. That is not
ideal, but was the best solution of the alternatives I could come up
with. The options I considered were:
- make use of the type system to add type safety to the test suite: This
required making a lot of changes to the test suite, since most of the
strings would now become byte objects instead, and it was not even
fully clear to me where to draw the line. One extreme solution would
be to just use byte objects everywhere, as the protocol doesn't
support non-ascii characters anyway. However, this appeared to be:
a) weird, because most of the protocol actually deals with strings,
but we would have to prefix everything with 'b'
b) clunky, because the handling of the bytes objects is sufficiently
different in PY2 and PY3 (e.g. b'a'[0] is a string in PY2, but an
int in PY3).
- using the latin1 codec (which gives an identity transformation for the
first 256 code points of unicode) instead of the custom
bytes_to_string functions. This almost could work, but it was still
slightly different between python 2 and 3, because in PY2 in would
return a unicode object, which would then cause problems when
combined with regular strings if it contained 8-bit chars.
With this in mind, I think the best solution for the time being is to
just coerce everything into the string type as early as possible, and
have things proceed indentically on both python versions. Once we stop
supporting python3, we can revisit the idea of using bytes objects more
prevasively.
Reviewers: davide, zturner, serge-sans-paille
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D58177
llvm-svn: 354106
Summary:
Instead of doing string chopping on the resulting python file, get swig
to output the version for us. The two things which make slightly
non-trivial are:
- in order to get swig to expand SWIG_VERSION for us, we cannot use
%pythoncode directly, but we have to go through an intermediate macro.
- SWIG_VERSION is a hex number, but it's components are supposed to be
interpreted decimally, so there is a bit of integer magic needed to
get the right number to come out.
I've tested that this approach works both with the latest (3.0.12) and
oldest (1.3.40) supported swig.
Reviewers: zturner, jingham, serge-sans-paille
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D58172
llvm-svn: 354104
dotest's version comparision function is just a lexicographical compare
of the version strings. This is obviously wrong. This patch implements
the comparison using distutils.version.LooseVersion as suggested by
Zachary.
Reviewers: zturner, labath, serge-sans-paille
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D58219
llvm-svn: 354047
This patch properly extracts the full submodule path as well as its
search paths from DWARF import decls and passes it on to the
ClangModulesDeclVendor.
rdar://problem/47970144
Differential Revision: https://reviews.llvm.org/D58090
llvm-svn: 353961
It looks like I was too hasty to submit the previous patch. It does fix
some tests on python3, but it also breaks one tests with python2.
This happens because the gdb-remote protocol can sometimes (but not very
often) contain binary data, and attempting to parse this as utf8
characters fails.
This reverts commit r353944.
llvm-svn: 353945
An equivalent change was made to RemapPaths, but it needed to be made
here as well. Also added a test for this and made the setup a little
more complex to avoid false successes.
<rdar://problem/47642498>
Differential Revision: https://reviews.llvm.org/D57552
llvm-svn: 353243
Summary:
This patch adds support of expression evaluation in a context of some object.
Consider the following example:
```
struct S {
int a = 11;
int b = 12;
};
int main() {
S s;
int a = 1;
int b = 2;
// We have stopped here
return 0;
}
```
This patch allows to do something like that:
```
lldb.frame.FindVariable("s").EvaluateExpression("a + b")
```
and the result will be `33` (not `3`) because fields `a` and `b` of `s` will be
used (not locals `a` and `b`).
This is achieved by replacing of `this` type and object for the expression. This
has some limitations: an expression can be evaluated only for values located in
the debuggee process memory (they must have an address of `eAddressTypeLoad`
type).
Reviewers: teemperor, clayborg, jingham, zturner, labath, davide, spyffe, serge-sans-paille
Reviewed By: jingham
Subscribers: abidh, lldb-commits, leonid.mashinskiy
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D55318
llvm-svn: 353149
One considers it integer division, the other doesn't.
Move to `//` (floor division) so that this test passes
independently from the version.
llvm-svn: 352706
Summary:
When we are creating a ClassTemplateSpecializationDecl in ParseTypeFromDWARF(...) we are not handling the case where variadic pack is empty in the specialization. This patch handles that case and adds a test to prevent future regressions.
Differential Revision: https://reviews.llvm.org/D57363
llvm-svn: 352677
This fixes most references to the paths:
llvm.org/svn/
llvm.org/git/
llvm.org/viewvc/
github.com/llvm-mirror/
github.com/llvm-project/
reviews.llvm.org/diffusion/
to instead point to https://github.com/llvm/llvm-project.
This is *not* a trivial substitution, because additionally, all the
checkout instructions had to be migrated to instruct users on how to
use the monorepo layout, setting LLVM_ENABLE_PROJECTS instead of
checking out various projects into various subdirectories.
I've attempted to not change any scripts here, only documentation. The
scripts will have to be addressed separately.
Additionally, I've deleted one document which appeared to be outdated
and unneeded:
lldb/docs/building-with-debug-llvm.txt
Differential Revision: https://reviews.llvm.org/D57330
llvm-svn: 352514
When running the test suite on macOS with Python 3 we noticed a
difference in behavior between Python 2 and Python 3 for
seven.get_command_output. The output contained a newline with Python 3,
but not for Python 2. This resulted in an invalid SDK path passed to the
compiler.
Differential revision: https://reviews.llvm.org/D57275
llvm-svn: 352397
This makes it easier to exclude the test n bots that test earlier
DWARF formats, also it feels like this is the better decision for this
testcase anyway.
llvm-svn: 352111
We figured out the issue so the logging is no longer necessary. It turns
out we were using a session format that was not unique for inline tests.
llvm-svn: 351902
The new LLVM header is one line shorter than the old one, which lead to
some test failures. Ideally tests should rely on line numbers for
breakpoints or output, but that's a different discussion. Hopefully this
turns the bots green again.
llvm-svn: 351779
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
We're seeing an odd issue on GreenDragon's lldb-cmake-matrix. Dotest is
unable to move a log file (OSError: [Errno 2] No such file or
directory). The os.rename call is guarded with a check that the source
file and destination directory exist.
This wraps the call in a try-except that prints the source and
destination path to see which component seemingly doesn't exist.
llvm-svn: 351611
This patch changes the behavior when printing C++ function references:
where we previously would get a <could not determine size>, there is
now a <no summary available>. It's not clear to me whether this is a
bug or an omission, but it's one step further than LLDB previously
got.
Differential Revision: https://reviews.llvm.org/D56798
llvm-svn: 351376
Summary:
This patch allows to retrieve an address object for `ValueObject`'s children
retrieved through e.g. `GetChildAtIndex` or `GetChildMemberWithName`. It just
uses the corresponding method of the implementation object `m_impl` to achieve
that.
Reviewers: zturner, JDevlieghere, clayborg, labath, serge-sans-paille
Reviewed By: clayborg
Subscribers: leonid.mashinskiy, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D56147
llvm-svn: 351065
Summary:
In python 2, strings and bytes are the same, but they're not in
python 3, hence the return of read() needs an explicit conversion.
While I'm around, rename the return of Popen() from `pipe` to
`process`, as that's what Popen returns.
Reviewers: JDevlieghere, friss, zturner, aprantl, serge-sans-paille
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D56517
llvm-svn: 350788
There is already in use:
lit/lit-lldb-init:
settings set symbols.enable-external-lookup false
packages/Python/lldbsuite/test/lldbtest.py:
self.runCmd('settings set symbols.enable-external-lookup false')
But those are not in effect during MI part of the testsuite. Another problem is
that symbols.enable-external-lookup (read by GetEnableExternalLookup) has been
currently read only by LocateMacOSXFilesUsingDebugSymbols and therefore it had
no effect on Linux.
On Red Hat platforms (Fedoras, RHEL-7) there is DWZ in use and so
MiSyntaxTestCase-test_lldbmi_output_grammar FAILs due to:
AssertionError: error: inconsistent pattern ''^.+?\n'' for state 0x5f
(matched string: warning: (x86_64) /lib64/libstdc++.so.6 unsupported
DW_FORM values: 0x1f20 0x1f21
It is the only testcase with this error. It happens due to:
(lldb) target create "/lib64/libstdc++.so.6"
Current executable set to '/lib64/libstdc++.so.6' (x86_64).
(lldb) b main
warning: (x86_64) /lib64/libstdc++.so.6 unsupported DW_FORM values: 0x1f20 0x1f21
Breakpoint 1: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.
which happens only with gcc-base-debuginfo rpm installed (similarly for other packages).
It should also speed up the testsuite as it no longer needs to read
/usr/lib/debug symbols which have no effect (and should not have any effect) on
the testsuite results.
Differential Revision: https://reviews.llvm.org/D55859
llvm-svn: 350368
TestQueues is failing randomly on green dragon and I suspect it is
because the enqueued threads haven't executed by the time we expect
them. This patch adds file-based synchronization to the queues.
Differential Revision: https://reviews.llvm.org/D56208
llvm-svn: 350247
python 3.7 removes re._pattern_type. Fix the one place where we were
depending on the type of regular expressions to compute the type
dynamically.
llvm-svn: 350093
They both run the same command, and people get used to typing the shortest
string they can, so we should support alias info on shortened strings as well.
<rdar://problem/46859207>
llvm-svn: 349874
These are tests that found actual, but hard to fix, bugs that are
tracked elsewhere. Leaving them red only distracts from new failures
this bot finds.
llvm-svn: 349851
This is a set of tests that were all marked as failing becuse of pr24764. The bug is not fixed (as in more of the tests that were marked this way are failing), but this set is passing. It is possible that some of them are false positives, but there's a large number of unexpectedly passing tests on Windows, so I am doing a bulk un-xfail to get the buildbot to green.
llvm-svn: 349719
This builds on https://reviews.llvm.org/D43884 and https://reviews.llvm.org/D43886 and extends LLDB support of Obj-C exceptions to also look for a "current exception" for a thread in the C++ exception handling runtime metadata (via call to __cxa_current_exception_type). We also construct an actual historical SBThread/ThreadSP that contains frames from the backtrace in the Obj-C exception object.
The high level goal this achieves is that when we're already crashed (because an unhandled exception occurred), we can still access the exception object and retrieve the backtrace from the throw point. In Obj-C, this is particularly useful because a catch+rethrow is very common and in those cases you currently don't have any access to the throw point backtrace.
Differential Revision: https://reviews.llvm.org/D44072
llvm-svn: 349718
This is a set of tests that were all marked as failing becuse of several different bugs. A couple of the bugs are now resolved as fixed since all the tests that were failing associated with the bug are now passing. It is possible that some of them are false positives, but there's a large number of unexpectedly passing tests on Windows, so I am doing a bulk un-xfail to get the buildbot to green.
llvm-svn: 349713
This is a set of tests that were all marked as failing becuse of several different bugs. A couple of the bugs are now resolved as fixed since all the tests that were failing associated with the bug are now passing. It is possible that some of them are false positives, but there's a large number of unexpectedly passing tests on Windows, so I am doing a bulk un-xfail to get the buildbot to green.
llvm-svn: 349711
This is a set of tests that were all marked as failing becuse of pr21765. The bug is not fixed (as in more of the tests that were marked this way are failing), but this set is passing. It is possible that some of them are false positives, but there's a large number of unexpectedly passing tests on Windows, so I am doing a bulk un-xfail to get the buildbot to green.
llvm-svn: 349668
This is a set of tests that were all marked as failing becuse of pr24489. The bug is not fixed (as in more of the tests that were marked this way are failing), but this set is passing. It is possible that some of them are false positives, but there's a large number of unexpectedly passing tests on Windows, so I am doing a bulk un-xfail to get the buildbot to green.
llvm-svn: 349665
Prior to this change we would show the name of the section that a memory region belonged to but not its actual region name. Now we show this,. Added a test that reuses the regions-linux-map.dmp minidump file to test this and verify the correct region names for various memory regions.
Differential Revision: https://reviews.llvm.org/D55854
llvm-svn: 349658
Currently spawnLldbMi accepts both lldb-mi options and executable to debug as
a single parameter. Split them.
As in D55859 we will need to execute one lldb-mi command before loading the
exe. Therefore we can no longer use the exe as lldb-mi command-line parameter
as then there is no way to execute a command before loading exe specified as
lldb-mi command-line parameter.
LocateExecutableSymbolFileDsym should be static, that is also a little
refactorization.
Differential Revision: https://reviews.llvm.org/D55858
llvm-svn: 349607
the "self.assertEqual(thread.GetStopReason(), lldb.eStopReasonSignal)"
was occasionally failing because the stop reason would come out as
"trace" this happened if we issued the interrupt just as the processed
stopped due to single-stepping over the breakpoint (i.e., the it was not
necessary to send any signal).
Fix this by removing the breakpoint before resuming the process. This
ensures the process can run unobstructed.
After this, the test passed 200 consecutive runs successfully for me,
even while the system was under heavy load.
llvm-svn: 349491
This test was disabled in r326756 as a part of "upstreaming debugserver
support for AVX-512 (zmm register set)". This looks like an error
because both register set and remote stubs are different.
In any case, the test passes now.
llvm-svn: 349485
This test is passing now on linux. The same test is claimed to be flaky
on darwin, so it's possible that's true on linux too. If that's the case
we'll have to skip it here too (or fix it).
I mark the test as not-debug-info-dependent as a drive-by.
llvm-svn: 349482
These tests are now passing on linux, at least with top-of-tree clang,
clang-6 and gcc-7.3. It's possible it may still be failing with some
older compilers, but I don't have those around to test.
llvm-svn: 349478
Alex Langford