| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D62221
Patch by Guilherme Andrade <guiandrade@google.com>.
llvm-svn: 362063
|
|
|
|
|
|
|
| |
Two tests having the same name creates a race condition when moving the
trace files.
llvm-svn: 361310
|
|
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D59015
Patch by Anton Kolesov <Anton.Kolesov@synopsys.com>
llvm-svn: 361255
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 360800
|
|
|
|
| |
llvm-svn: 360767
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
Authored by: Lukas Boger
Differential Revision: https://reviews.llvm.org/D61602
llvm-svn: 360730
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D61883
llvm-svn: 360654
|
|
|
|
| |
llvm-svn: 360564
|
|
|
|
| |
llvm-svn: 360482
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
happy."
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
|
|
|
|
|
|
|
|
|
|
| |
calls and stepping into and them out of each one
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
|
|
|
|
|
|
| |
Thanks to Pavel for pointing this out.
llvm-svn: 359925
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 359846
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-matrix/
llvm-svn: 359812
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: aprantl, shafik
Reviewed By: aprantl, shafik
Subscribers: lldb-commits
Tags: #c_modules_in_lldb, #lldb
Differential Revision: https://reviews.llvm.org/D61305
llvm-svn: 359779
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
when loading from DWARF
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
lookup correctly
Summary:
Some tests currently only work because we are pulling all the local variables when we are evaluating an expression. This will soon
change and these test are working but for the wrong reasons. The details can be found in the discussion here:
http://lists.llvm.org/pipermail/lldb-commits/Week-of-Mon-20180507/040689.html
Differential Review: https://reviews.llvm.org/D61266
llvm-svn: 359699
|
|
|
|
|
|
| |
After Aaron's commit for ObjectFilePECOFF:: GetUUID, the tests are now passing
llvm-svn: 359573
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 359452
|
|
|
|
| |
llvm-svn: 359440
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 359347
|
|
|
|
| |
llvm-svn: 359249
|
|
|
|
| |
llvm-svn: 359240
|
|
|
|
|
|
|
| |
lldb.debugger. They should not be.
<rdar://problem/50210340>
llvm-svn: 359234
|
|
|
|
|
|
|
| |
Not sure what is or is not supposed to work on Windows and I have
no way to investigate this.
llvm-svn: 359145
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pointers and references and adding a test to cover a previous related fix
Summary:
This previous fix https://github.com/llvm-mirror/lldb/commit/5469bda296c183d1b6bf74597c88c9ed667b3145 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
|
|
|
|
| |
llvm-svn: 358924
|
|
|
|
| |
llvm-svn: 358848
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|