Summary:
According to [C128] "Virtual functions should specify exactly one
of `virtual`, `override`, or `final`", I've added override where a
virtual function is overriden but the explicit `override` keyword
was missing. Whenever both `virtual` and `override` were specified,
I removed `virtual`. As C.128 puts it:
> [...] writing more than one of these three is both redundant and
> a potential source of errors.
I anticipate a discussion about whether or not to add `override` to
destructors but I went for it because of an example in [ISOCPP1000].
Let me repeat the comment for you here:
Consider this code:
```
struct Base {
virtual ~Base(){}
};
struct SubClass : Base {
~SubClass() {
std::cout << "It works!\n";
}
};
int main() {
std::unique_ptr<Base> ptr = std::make_unique<SubClass>();
}
```
If for some odd reason somebody removes the `virtual` keyword from the
`Base` struct, the code will no longer print `It works!`. So adding
`override` to destructors actively protects us from accidentally
breaking our code at runtime.
[C128]: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#c128-virtual-functions-should-specify-exactly-one-of-virtual-override-or-final
[ISOCPP1000]: https://github.com/isocpp/CppCoreGuidelines/issues/1000#issuecomment-476951555
Reviewers: teemperor, JDevlieghere, davide, shafik
Reviewed By: teemperor
Subscribers: kwk, arphaman, kadircet, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D61440
llvm-svn: 359868
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
logging messages that are written the same, making it difficult to
know for certain which code path was taken based on a logfile. Add
some words to make each unique.
Right now the ordering for finding a FullUnwindPlan (ignoring
fallback unwind plan logic) is
1. If this is a _sigtramp like function, try eh_frame which is
hand written on darwin systems to account for finding the
saved register context correctly.
2. Ask the DynamicLoader if eh_frame should be preferred for
this frame. Some binaries on the system may have hand-written
eh_frame and the DynamicLoader is the source for this. (primarily
this is for hand-written assembly in the objc runtime, and we tell
lldb to trust that for functions in libobjc.dylib.)
3. if 0th frame, use GetUnwindPlanAtNonCallSite plan.
4. GetUnwindPlanAtCallSite {for 0th or any other}
5. GetUnwindPlanAtNonCallSite {now for non-0th frames, only if not from a compiler? hm.}
6. GetUnwindPlanArchitectureDefaultAtFunctionEntry if we're on the first instruction
7. Architectural default unwind plan ABI::CreateDefaultUnwindPlan
I'm moving #6 -- DefaultAtFunctionEntry -- up to between #3 and #4,
where we're already doing things specific to the zeroth frame. If
we're on the zeroth frame and the GetUnwindPlanAtNonCallSite plan
has failed for some reason, and we're on the first instruction, we
should definitely use DefaultAtFunctionEntry instead of any other
unwind plan. If we're trying to step out of some rando function
on the system that we couldn't assembly instruction inspect, this
is sufficient for us to step out of it.
llvm-svn: 359847
lldb has an expression that runs in the inferior process to collect
the isa values and hash of the class names for classes in the
system's shared cache. In recent OSes, swift classes are in this
table and the function the jitted expression calls returns demangled
names. We need to compute the hashes based on the mangled names.
So for these names, return a hash value of 0 which indicates that
lldb should read the class name directly out of the runtime tables
and compute the hash itself.
When this patch is absent, the lldb+swift testsuite has many failures
on a recent macOS system; there isn't a direct non-swift way to
test for this being correct.
<rdar://problem/47935062>
llvm-svn: 359843
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
The debug server does not need to use the instruction emulation. This helps
reduce the size of the final lldb-server binary by another ~100K (~1% savings).
llvm-svn: 359832
`_MSC_VER` indiciates that you are building with MSVC, not that you are building
for Windows. Use `_WIN32` (which identifies Win32 and Win64).
llvm-svn: 359817
Summary:
This check seems unnecessary as we already assert the same condition above and also access `sc.comp_unit`
before this check.
Reviewers: aprantl
Reviewed By: aprantl
Subscribers: jdoerfert, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D61394
llvm-svn: 359813
This restructures the initialization path to move the ObjectContainer
initialization into the *full* initialization path. This is not needed
for the lldb-server initialization path. This helps strip off ~1MiB
from the binary.
llvm-svn: 359810
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
Since Darwin target implements support for zmm* registers without
matching support for the respectively added xmm* and ymm* registers,
split the tests for each register group. To reduce code duplication,
the tests are using the same source file (which sets more registers
than necessary but that should not cause any harm).
Differential Revision: https://reviews.llvm.org/D61376
llvm-svn: 359780
Summary:
I think there universal agreement that Minion isn't the best name for this class. This patch renames the class
to ASTImporterDelegate to better reflect it's goal of monitoring and extending the ASTImporter.
Reviewers: aprantl, shafik, martong, a.sidorin, davide
Reviewed By: aprantl, shafik, davide
Subscribers: rnkovacs, davide, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D61299
llvm-svn: 359777
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
Address an ambiguity between lldb_private::Thread and
llvm::minidump::Thread. Follow-up to llvm r359762 (which introduced the
second type).
llvm-svn: 359765
You can only find out about this useful customization by browsing
the settings list output or the llvm.org web pages. Mention it
in the help for thread list, thread backtrace & _regex_bt commands
to make it more discoverable.
llvm-svn: 359752
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
This patch ensures that we honor the stop-command-source-on-error
setting from `command source`. The problem is that we didn't
differentiate between the boolean value being true or false, or not
being set. For the latter scenario, we should calculate the value in the
command interpreter based on the global options.
Differential revision: https://reviews.llvm.org/D61406
llvm-svn: 359750
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
Fix bugs in piod_len return value processing in ReadMemory()
and WriteMemory() methods. In particular, add support for piod_len == 0
indicating EOF, and fix summing bytes_read/bytes_written when PT_IO does
partial reads/writes.
The EOF condition could happen if LLDB attempts to read past
vm.maxaddress, e.g. as a result of RBP containing large (invalid) value.
Previously, the 0 return caused the function to retry reading via PT_IO
indefinitely, effectively deadlooping lldb-server.
Partial reads probably did not occur in practice, yet they would cause
ReadMemory() to return incorrect bytes_read and/or overwrite previously
read data.
WriteMemory() suffered from analoguous problems.
Differential Revision: https://reviews.llvm.org/D61310
llvm-svn: 359572
Summary:
This node represents can be used to refer to the initial value, which is
sometimes pushed onto the DWARF stack as the "input" to the DWARF
expression. The typical use case (and the reason why I'm introducing it)
is that the "Canonical Frame Address" is passed this way to the DWARF
expressions computing the values of registers during frame unwind.
The nodes are converted into dwarf by keeping track of DWARF stack depth
an any given point, and then copying the initial value from the bottom
of the stack via the DW_OP_pick opcode. This could be made more
efficient for simple expressions, but here I chose to start with the
most general implementation possible.
Reviewers: amccarth, clayborg, aleksandr.urakov
Subscribers: aprantl, jasonmolenda, lldb-commits, markmentovai
Differential Revision: https://reviews.llvm.org/D61183
llvm-svn: 359560
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
Raphael Isemann