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
