Summary:
This patch implements missing case in PdbAstBuilder::CreateType for
LF_MFUNCTION. This is necessary, for example, in stack unwinding of struct
methods.
Reviewers: amccarth, aleksandr.urakov
Reviewed By: amccarth
Subscribers: abidh, teemperor, lldb-commits, leonid.mashinskiy
Differential Revision: https://reviews.llvm.org/D61128
llvm-svn: 360569
Summary:
Instead of using the offset of the contained compile unit, we use it's
ID. The goal of this change is two-fold:
- free up space in the user_id_t representation to enable storing the
debug-info-carrying section (debug_types/debug_info) without
decreasing the amount of debug info we can address (as would be the
case with D61503).
- be a step towards supporting DWO files containing more than one unit
(important for debug_types+dwo, but can also happen with regular
dwo+lto). For this part to fully work we'd still need to add a way to
lookup the SymbolFileDWO without going through GetCompileUnitAtIndex,
but making sure things don't accidentally work because the SymbolFile
ID is the same as compile unit offset is a step towards that.
Reviewers: JDevlieghere, clayborg, aprantl
Subscribers: mehdi_amini, dexonsmith, tberghammer, jankratochvil, lldb-commits
Differential Revision: https://reviews.llvm.org/D61783
llvm-svn: 360565
Summary:
Breakpoint shouldn't need to depend on any specific details from a
programming language. Currently the only language-specific detail it takes
advantage of are the different qualified names an objective-c method name might
have when adding a name lookup. This is reasonably generalizable.
The current method name I introduced is "GetVariantMethodNames", which I'm not
particularly tied to. If you have a better suggestion, please do let me know.
Reviewers: JDevlieghere, jingham, clayborg
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D61746
llvm-svn: 360509
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
D42892 changed a lot of code to use superclass DWARFUnit instead of its
subclass DWARFCompileUnit.
Finish this change more thoroughly for any *CompileUnit* -> *Unit* names.
Later patch will introduce DWARFTypeUnit which needs to be sometimes different
from DWARFCompileUnit and it would be confusing without this renaming.
Differential Revision: https://reviews.llvm.org/D61501
llvm-svn: 360443
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
Summary:
some unwind formats are specific to a single symbol file and so it does
not make sense for their parsing code live in the general Symbol library
(as is the case with eh_frame for instance). This is the case for the
unwind information in breakpad files, but the same will probably be true
for PDB unwind info (once we are able to parse that).
This patch adds the ability to fetch an unwind plan provided by a symbol
file plugin, as discussed in the RFC at
<http://lists.llvm.org/pipermail/lldb-dev/2019-February/014703.html>.
I've kept the set of changes to a minimum, as there is no way to test
them until we have a symbol file which implements this API -- that is
comming in a follow-up patch, which will also implicitly test this
change.
The interesting part here is the introduction of the
"RegisterInfoResolver" interface. The reason for this is that breakpad
needs to be able to resolve register names (which are present as strings
in the file) into register enums so that it can construct the unwind
plan. This is normally done via the RegisterContext class, handing this
over to the SymbolFile plugin would mean that it has full access to the
debugged process, which is not something we want it to have. So instead,
I create a facade, which only provides the ability to query register
names, and hide the RegisterContext behind the facade.
Also note that this only adds the ability to dump the unwind plan
created by the symbol file plugin -- the plan is not used for unwinding
yet -- this will be added in a third patch, which will add additional
tests which makes sure the unwinding works as a whole.
Reviewers: jasonmolenda, clayborg
Subscribers: markmentovai, amccarth, lldb-commits
Differential Revision: https://reviews.llvm.org/D61732
llvm-svn: 360409
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
All the other paths in the find_toolchain function return a tuple
(detected_toolchain_type, compiler_path), but when the parameter to
--compiler is not one of the predefined names it only returns the
detected toolchain type, which causes an error when trying to unpack the
result.
This patch changes it to return also the compiler path passed as a
parameter.
Differential Revision: https://reviews.llvm.org/D61713
llvm-svn: 360355
Summary:
First part of a fix for JITed code debugging. This has been a regression from 5.0 to 6.0 and it's is still reproducible on current master: https://bugs.llvm.org/show_bug.cgi?id=36209
The address of the breakpoint site is corrupt: the 0x4 value we end up with, looks like an offset on a zero base address. When we parse the ELF section headers from the JIT descriptor, the load address for the text section we find in `header.sh_addr` is correct.
The bug manifests in `VMAddressProvider::GetVMRange(const ELFSectionHeader &)` (follow it from `ObjectFileELF::CreateSections()`). Here we think the object type was `eTypeObjectFile` and unleash some extra logic [1] which essentially overwrites the address with a zero value.
The object type is deduced from the ELF header's `e_type` in `ObjectFileELF::CalculateType()`. It never returns `eTypeJIT`, because the ELF header has no representation for it [2]. Instead the in-memory ELF object states `ET_REL`, which leads to `eTypeObjectFile`. This is what we get from `lli` at least since 3.x. (Might it be better to write `ET_EXEC` on the JIT side instead? In fact, relocations were already applied at this point, so "Relocatable" is not quite exact.)
So, this patch proposes to set `eTypeJIT` explicitly whenever we read from a JIT descriptor. In `ObjectFileELF::CreateSections()` we can then call `GetType()`, which returns the explicit value or otherwise falls back to `CalculateType()`.
LLDB then sets the breakpoint successfully. Next step: debug info.
```
Process 1056 stopped
* thread #1, name = 'lli', stop reason = breakpoint 1.2
frame #0: 0x00007ffff7ff7000 JIT(0x3ba2030)`jitbp()
JIT(0x3ba2030)`jitbp:
-> 0x7ffff7ff7000 <+0>: pushq %rbp
0x7ffff7ff7001 <+1>: movq %rsp, %rbp
0x7ffff7ff7004 <+4>: movabsq $0x7ffff7ff6000, %rdi ; imm = 0x7FFFF7FF6000
0x7ffff7ff700e <+14>: movabsq $0x7ffff6697e80, %rcx ; imm = 0x7FFFF6697E80
```
[1] It was first introduced with https://reviews.llvm.org/D38142#change-lF6csxV8HdlL, which has also been the original breaking change. The code has changed a lot since then.
[2] ELF object types: https://github.com/llvm/llvm-project/blob/2d2277f5/llvm/include/llvm/BinaryFormat/ELF.h#L110
Reviewers: labath, JDevlieghere, bkoropoff, clayborg, espindola, alexshap, stella.stamenova
Reviewed By: labath, clayborg
Subscribers: probinson, emaste, aprantl, arichardson, MaskRay, AlexDenisov, yurydelendik, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D61611
llvm-svn: 360354
The script phase to do Options.td -> Options.inc was
wrong (missing the "include" directory) so the rule didn't
get run when Options.td changed.
llvm-svn: 360304
I think the recent change to flush the SB API recording uncovered a real
issue on the Windows bot. Although I couldn't make much sense of the
error message "unknown file: error: SEH exception with code 0x3221225477
thrown in the test body.", it prompted me to look at the test. In the
unit test we were recording during replay, which is obviously not
correct. I think we didn't see this issue before because we flushed once
after the recording was done. This patch unsets the recording logic
during the replay part of the test.
Hopefully this fixed the Windows bot.
llvm-svn: 360298
Previous ArchSpec tests didn't catch this bug since we never tested just the OS being out of date. Fixed the bug and covered this with a test that would catch this.
This was found when trying to load a core file where the core file was an ELF file with just the e_machine for architeture and where the ELF header had no OS set in the OSABI field of the e_ident. It wasn't merging the architecture with the target architecture correctly.
Differential Revision: https://reviews.llvm.org/D61659
llvm-svn: 360292
The run command is only an abbreviation for the more verbose process
launch -- <args> but it works just as with GDB and therefore should be
mentioned in the GDB to LLDB command map.
For educational purposes I've not listed it as the first option on the
LLDB side so that new LLDB user can, if they want, also know what the
"native" way is for LLDB.
Here's the help documentation for the run command in lldb which gives
proof:
> (lldb) help run
> Launch the executable in the debugger.
>
> Syntax: run [<run-args>]
>
> Command Options Usage:
> run [<run-args>]
>
> 'run' is an abbreviation for 'process launch -c /bin/sh --'
Patch by: Konrad Kleine
Differential revision: https://reviews.llvm.org/D61483
llvm-svn: 360269
Summary:
The logic for translating a user_id into a DWARFDIE was replicated in
several places. This removes that redundancy and settles on a single
implementation in SymbolFileDWARF.
The reason for choosing that instead of DIERef was that we were
always immediately converting the returned DIERef into a DWARFDIE
anyway, which meant that one had to specify the SymbolFileDWARF argument
twice (once to get the DIERef, and once to get the actual DIE). Also,
passing a higher-level object (SymbolFileDWARF) into a lower-level one
(DIERef) seemed like a less intuitive arrangement than doing things the
other way around.
Reviewers: JDevlieghere, clayborg, aprantl
Subscribers: tberghammer, jankratochvil, lldb-commits
Differential Revision: https://reviews.llvm.org/D61648
llvm-svn: 360246
This patch fixes two incorrect headings in source.rst which caused it to
show up on the homepage. I also updated the titles to have more sensible
links there.
llvm-svn: 360219
This patch ensures that we propagate errors coming from the lldbinit
file trough the command/script interpreter. Before, if you did something
like command script import syntax_error.py, and the python file
contained a syntax error, lldb wouldn't tell you about it. This changes
with the current patch: errors are now propagated by default.
PS: Jim authored this change and I added testing.
Differential revision: https://reviews.llvm.org/D61579
llvm-svn: 360216
lldbExpression was linking against lldbPluginExpressionParserClang, and
lldbPluginExpressionParserClang was linking against lldbExpression.
There's no reason lldbExpression should need anything from
lldbPluginExpressionParserClang, so let's remove that dependency.
llvm-svn: 360208
This patch adds a command line flag that allows lldb to load local
lldbinit files.
Differential revision: https://reviews.llvm.org/D61578
llvm-svn: 360172
Remove SymbolVendorMacOSX from the test, as this plugin is not available
on non-mac platforms, and it does not seem to be necessary anyway.
Declare inlined-functions.yaml as an input of the test in cmake.
llvm-svn: 360169
Summary:
This is necessary to support parsing expressions like ".cfa -16 + ^", as
that format is used in breakpad STACK CFI expressions.
Since the PDB expressions use the same parser, this change will affect
them too, but I don't believe that should be a problem in practice. If
PDBs do contain the negative values, it's very likely that they are
intended to be parsed the same way, and if they don't, then it doesn't
matter.
In case that we do ever need to handle this differently, we can always
make the parser behavior customizable, or just use a different parser.
To make sure that the integer size is big enough for everyone, I switch
from using a (unsigned) 32-bit integer to a 64-bit (signed) one.
Reviewers: amccarth, clayborg, aleksandr.urakov
Subscribers: markmentovai, lldb-commits
Differential Revision: https://reviews.llvm.org/D61311
llvm-svn: 360166
Summary:
This behavior is specified in the Section 6.4.2.3 (Register Rule
instructions) of the DWARF4 spec. We were not doing that, which meant
that any register rule which was relying on the cfa value being there
was not evaluated correctly (it was aborted due to "out of bounds"
access).
I'm not sure how come this wasn't noticed before, but I guess this has
something to do with the fact that dwarf unwind expressions are not used
very often, and when they are, the situation is so complicated that the
CFA is of no use. I noticed this when I started emitting dwarf
expressions for the unwind information present in breakpad symbol files.
Reviewers: jasonmolenda, clayborg
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D61018
llvm-svn: 360158
Fix Register tests to reference memory access to arrays via %0 and %1,
rather than via referencing %rax and %rbx directly. This fixes test
build failures on 32-bit x86.
llvm-svn: 360148
Summary:
r360109 added a new enum case, causing lldb build to fail with several errors like:
lldb/source/Symbol/ClangASTContext.cpp:4342:11: error: enumeration value 'MacroQualified' not handled in switch [-Werror,-Wswitch]
switch (qual_type->getTypeClass()) {
^
This adds the missing switch cases.
I'm not an lldb maintainer and just used my best judgement that it's probably expected that we break in these cases. Feel free to ping / revert / fix this change if this behavior is not appropriate.
Reviewers: gribozavr
Reviewed By: gribozavr
Differential Revision: https://reviews.llvm.org/D61640
llvm-svn: 360146
The CPlusPlus Language plugin is unused in lldbBreakpoint. We should just remove
it.
A great follow up to this change would be to remove the dependency on the ObjC
language plugin, but that is actually used and requires some refactoring.
llvm-svn: 360105
Currently we have special handling for local lldbinit files in the
driver. At the same time, we have an SB API named
`SourceInitFileInCurrentWorkingDirectory` that does the same thing.
This patch removes the special handling from the driver and uses the API
instead. In addition to the obvious advantages of having one canonical
way of doing things and removing code duplication, this change also
means that the code path is the same for global and local lldb init
files.
Differential revision: https://reviews.llvm.org/D61577
llvm-svn: 360077
Checking this in for Antonio Afonso:
This diff changes the function LineEntry::GetSameLineContiguousAddressRange so that it also includes function calls that were inlined at the same line of code.
My motivation is to decrease the step over time of lines that heavly rely on inlined functions. I have multiple examples in the code base I work that makes a step over stop 20 or mote times internally. This can easly had up to step overs that take >500ms which I was able to lower to 25ms with this new strategy.
The reason the current code is not extending the address range beyond an inlined function is because when we resolve the symbol at the next address of the line entry we will get the entry line corresponding to where the original code for the inline function lives, making us barely extend the range. This then will end up on a step over having to stop multiple times everytime there's an inlined function.
To check if the range is an inlined function at that line I also get the block associated with the next address and check if there is a parent block with a call site at the line we're trying to extend.
To check this I created a new function in Block called GetContainingInlinedBlockWithCallSite that does exactly that. I also added a new function to Declaration for convinence of checking file/line named CompareFileAndLine.
To avoid potential issues when extending an address range I added an Extend function that extends the range by the AddressRange given as an argument. This function returns true to indicate sucess when the rage was agumented, false otherwise (e.g.: the ranges are not connected). The reason I do is to make sure that we're not just blindly extending complete_line_range by whatever GetByteSize() we got. If for some reason the ranges are not connected or overlap, or even 0, this could be an issue.
I also added a unit tests for this change and include the instructions on the test itself on how to generate the yaml file I use for testing.
Differential Revision: https://reviews.llvm.org/D61292
llvm-svn: 360071
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: 360067
Replace the constants used for r8/mm/xmm/ymm/zmm tests with something
more readable to ease debugging in case of failures (0x00 0x01 ...).
While at it, put the constants in array and copy them from memory
to simplify inline asm.
The original constants grew out of necessity. The xmm constants were
'weird' because they were intended to be different from mm constants
(as that was necessary to catch NetBSD implementation bug). The ymm
constants were made even weirded to not even partially collide with
other xmm registers (not saying it made sense, just how it was done).
Then, zmm constants were once again designed to avoid accidental
collisions with xmm and ymm constants, and at the same the 16 extra
registers required even more shuffling.
The new constants are meant to be more user-readable, so that a mistake
could be easily spotted. All of xmm, ymm and zmm tests use a sequence
of {0x00 0x01 0x02 ...}, shifted by 1 for every register. This should
provide enough uniquity, and space for future increase in number of
registers. Since mm and r8..r15 are printed as uint64_t rather than
byte-by-byte, they use 0x000102... As a result, on x86 endianness takes
care of making mm different than xmm.
The use of arrays is something I had to learn for zmm write tests. It
avoids having to specify all the input values separately, and makes
GCC happy about zmm-read test (it was rejected previously because of
hitting a limit of 30 constraints).
llvm-svn: 360041
These two methods are very similar and various refactorizations need to modify
both similar ways.
One could also just remove GetCompileUnitAtOffset and make
GetCompileUnitContainingDIEOffset to also accept offset of the CU itself
(currently it accepts only DIE offsets after the CU header).
But that would be less safe regarding some internal sanity checking.
Further code refactorization has been suggested by Pavel Labath.
Differential Revision: https://reviews.llvm.org/D61498
llvm-svn: 360038
This caused Clang to start erroring on the following:
struct S {
template <typename = int> explicit S();
};
struct T : S {};
struct U : T {
U();
};
U::U() {}
$ clang -c /tmp/x.cc
/tmp/x.cc:10:4: error: call to implicitly-deleted default constructor of 'T'
U::U() {}
^
/tmp/x.cc:5:12: note: default constructor of 'T' is implicitly deleted
because base class 'S' has no default constructor
struct T : S {};
^
1 error generated.
See discussion on the cfe-commits email thread.
This also reverts the follow-ups r359966 and r359968.
> this patch adds support for the explicit bool specifier.
>
> Changes:
> - The parsing for the explicit(bool) specifier was added in ParseDecl.cpp.
> - The storage of the explicit specifier was changed. the explicit specifier was stored as a boolean value in the FunctionDeclBitfields and in the DeclSpec class. now it is stored as a PointerIntPair<Expr*, 2> with a flag and a potential expression in CXXConstructorDecl, CXXDeductionGuideDecl, CXXConversionDecl and in the DeclSpec class.
> - Following the AST change, Serialization, ASTMatchers, ASTComparator and ASTPrinter were adapted.
> - Template instantiation was adapted to instantiate the potential expressions of the explicit(bool) specifier When instantiating their associated declaration.
> - The Add*Candidate functions were adapted, they now take a Boolean indicating if the context allowing explicit constructor or conversion function and this boolean is used to remove invalid overloads that required template instantiation to be detected.
> - Test for Semantic and Serialization were added.
>
> This patch is not yet complete. I still need to check that interaction with CTAD and deduction guides is correct. and add more tests for AST operations. But I wanted first feedback.
> Perhaps this patch should be spited in smaller patches, but making each patch testable as a standalone may be tricky.
>
> Patch by Tyker
>
> Differential Revision: https://reviews.llvm.org/D60934
llvm-svn: 360024
Summary:
The implementation of GetID used a relatively complicated algorithm,
which returned some kind of an offset of the unit in some file
(depending on the debug info flavour). The only thing this ID was used
for was to enable subseqent retrieval of the unit from the SymbolFile.
This can be made simpler if we just make the "ID" of the unit an index
into the list of the units belonging to the symbol file. We already
support indexed access to the units, so each unit already has a well
"index" -- this just makes it accessible from within the unit.
To make the distincion between "id" and "offset" clearer (and help catch
any misuses), I also rename DWARFDebugInfo::GetCompileUnit (which
accesses by offset) into DWARFDebugInfo::GetCompileUnitAtOffset.
On its own, this only brings a minor simplification, but it enables
further simplifications in the DIERef class (coming in a follow-up
patch).
Reviewers: JDevlieghere, clayborg, aprantl
Subscribers: arphaman, jdoerfert, lldb-commits, tberghammer, jankratochvil
Differential Revision: https://reviews.llvm.org/D61481
llvm-svn: 360014
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
Use output constraints for specific general-purpose registers in order
to simplify the tests. They save us from having to manually put
the values in correct registers, and reduce the number of registers
needed as a result.
llvm-svn: 359978
This was added to support FreeBSD. The inclusion of this header increases the
size of `lldb-server` due to MCJIT being forcefully preserved. Conditionalise
the inclusion to shared builds of LLVM which will allow for MCJIT to be stripped
if unnecessary when performing static linking of tools. This shaves off ~28% of
the binary size for lldb-server when linked with gold using
`-ffunction-sections` and `-fdata-sections`.
llvm-svn: 359944
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
Before this change the test would always pass if the path to the test
contained the number 11 in it. Thanks to Ted for pointing this out.
llvm-svn: 359930
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
We don't need the variables in lit, we can use the capabilities to check
if the utility exists.
Differential revision: https://reviews.llvm.org/D61533
llvm-svn: 359926
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
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
Apparently setting the per-test-timeout and not having the psutil
package constitutes to a fatal error. So only set the timeout when the
module is available.
llvm-svn: 359503
The timeout wasn't working because it's a property of the lit
configuration, not of the configuration in lit.site.cfg. This sets the
property for the correct object.
llvm-svn: 359492
CMake specifies that the DEPENDS field of add_custom_target is for files
and output of add_custom_command. In order to add a target dependency,
add_dependencies should be used.
llvm-svn: 359490
GetSDKVersion expects the number of version fields not their byte size
and will happily overwrite later contents of the stack.
Differential Revision: https://reviews.llvm.org/D61218
llvm-svn: 359471
As discussed on the mailing list, we should be able to generate the
Python reference without building all of LLDB. To make that possible I
create a dummy python package, which is then parsed by epydoc. The
latter will complain that it couldn't import lldb, but that doesn't
matter as far as generation of the docs is concerned.
Differential revision: https://reviews.llvm.org/D61216
llvm-svn: 359465
Their functionality overlaps with the newly introduced
PostfixExpressionTests (r359288). Tests, which still exercise some
pdb-related functionality (register name resolution) have been kept.
llvm-svn: 359450
Summary:
libedit implementation of el_get(EL_GETTC) had a bug, where it was
consuming vararg arguments until reaching the first null pointer (and
not just two, as documented). This was causing (at least) errors to be
reported when running the tests under msan.
The issue has since been fixed in libedit, but this adds patch adds a
trivial workaround, so that we operate correctly with the libedit
versions which are already out there.
Reviewers: christos, krytarowski, davide
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D61191
llvm-svn: 359449
Introduce two initial tests for 'register write' command. The tests
first clobber x86 general purpose registers, then call int3 to let lldb
write to them, then print the new values. FileCheck takes care of
verifying whether correct values were written.
Differential Revision: https://reviews.llvm.org/D61221
llvm-svn: 359441
Introduce tests for reading the eight x86 general purpose registers,
i.e. RAX/RBX/RCX/RDX/RBP/RSP/RSI/RDI and their shorter counterparts.
The test comes in separate 32-bit and 64-bit variant, targeting
appropriate processors.
While technically the 32-bit test could run on amd64, it would be
redundant to the 64-bit version, so just run one of them on each arch.
Differential Revision: https://reviews.llvm.org/D61210
llvm-svn: 359438
Summary:
The DWARF spec states that the DWARF stack arguments are numbered from
the top. Our implementation of DW_OP_pick was counting them from the
bottom.
This bug probably wasn't noticed because nobody (except my upcoming
postfix-to-DWARF converter) uses DW_OP_pick, but I've cross-checked with
gdb to confirm that counting from the top is the expected behavior.
This patch fixes the implementation to match the spec and gdb behavior
and adds a test.
Reviewers: jasonmolenda, clayborg
Subscribers: mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D61182
llvm-svn: 359436
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:
As reported in LLVM bug 41487, the check in this function is wrong and should be
the same as the described check in the comment (which is correctly copied from the
ARM ISA reference).
Reviewers: #lldb, davide, JDevlieghere
Reviewed By: #lldb, davide, JDevlieghere
Subscribers: davide, javed.absar, kristof.beyls, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D60654
llvm-svn: 359387
In r359354 a GetDebugger() method was added to the CommandObject class,
so that we didn't have to go through the command interpreter to obtain
the script interpreter. This patch simplifies other call sites where
m_interpreter.GetDebugger() was used, and replaces them with a shorter
call to the new method.
llvm-svn: 359373
The FormatType enum and corresponding field are unused. This patch
removes the type, field and simplifies the macros that initialize them.
llvm-svn: 359372
Remove unused from the driver class. I noticed a bunch of small thing
while doing this that didn't warrant separate commits, so I've lumped
them together into this patch.
llvm-svn: 359355
This is part two of the change started in r359330. This patch moves the
ownership of the script interpreter from the command interpreter into
the debugger. I would've preferred to remove the lazy initialization,
however the fact that the scripting language is set after the debugger
is created makes that tricky. So for now this does exactly the same
thing as when it was under the command interpreter. The result is that
this patch is fully NFC.
Differential revision: https://reviews.llvm.org/D61211
llvm-svn: 359354
stop-hook-threads.cpp uses C++11 features, so ask for C++11 explicitely.
This isn't broken on mainstream because clang defaults to a newer C++
version now, but it breaks if testing against an older compiler.
llvm-svn: 359349
The script language argument was passed from the debugger to the command
interpreter, only to call SetScriptLanguage on the debugger again. It
wasn't even used to initialize the script interpreter, because that
would query the debugger again. This patch removes the needless back and
forth.
llvm-svn: 359346
As discussed in D61090, there's no good reason for the script
interpreter to depend on the command interpreter. When looking at the
code, it becomes clear that we mostly use the command interpreter as a
way to access the debugger. Hence, it makes more sense to just pass that
to the script interpreter directly.
This is part 1 out of 2. I have another patch in the pipeline that
changes the ownership of the script interpreter to the debugger as well,
but I didn't get around to finish that today.
Differential revision: https://reviews.llvm.org/D61172
llvm-svn: 359330
Add a new lit-cpuid tool that detects CPU features used by some of
the tests, and use it to populate available_features in lit. For now,
this means that the test for MM/XMM register read will be run only
when the host CPU support SSE instruction set. However, this is going
to make it possible to introduce additional tests relying on AVX.
Differential Revision: https://reviews.llvm.org/D61073
llvm-svn: 359303
Summary:
The new dwarf generator is pretty much a verbatim copy of the one in
PDB.
In order to write a pdb-independent test for it, I needed to write a
dummy "symbol resolver", which (together with the fact that I'll need
one more for breakpad-specific resolution logic) prompted me to create a
more simple interface for algorithms which replace or "resolve"
SymbolNodes. The resolving algorithms in NativePDB have been updated to
make use of that too.
I have removed a couple of NativePDB tests which weren't testing
anything pdb-specific and where the tested functionality was covered by
the new format-agnostic tests I have added.
Reviewers: amccarth, clayborg, aleksandr.urakov
Subscribers: aprantl, markmentovai, lldb-commits, jasonmolenda, JDevlieghere
Differential Revision: https://reviews.llvm.org/D61056
llvm-svn: 359288
Summary:
When we want to compare a ConstString against a string literal (or any other non-ConstString),
we currently have to explicitly turn the other string into a ConstString. This makes sense as
comparing ConstStrings against each other is only a fast pointer comparison.
However, currently we (rather incorrectly) use in several places in LLDB temporary ConstStrings when
we just want to compare a given ConstString against a hardcoded value, for example like this:
```
if (extension != ConstString(".oat") && extension != ConstString(".odex"))
```
Obviously this kind of defeats the point of ConstStrings. In the comparison above we would
construct two temporary ConstStrings every time we hit the given code. Constructing a
ConstString is relatively expensive: we need to go to the StringPool, take a read and possibly
an exclusive write-lock and then look up our temporary string in the string map of the pool.
So we do a lot of heavy work for essentially just comparing a <6 characters in two strings.
I initially wanted to just fix these issues by turning the temporary ConstString in static variables/
members, but that made the code much less readable. Instead I propose to add a new overload
for the ConstString comparison operator that takes a StringRef. This comparison operator directly
compares the ConstString content against the given StringRef without turning the StringRef into
a ConstString.
This means that the example above can look like this now:
```
if (extension != ".oat" && extension != ".odex")
```
It also no longer has to unlock/lock two locks and call multiple functions in other TUs for constructing
the temporary ConstString instances. Instead this should end up just being a direct string comparison
of the two given strings on most compilers.
This patch also directly updates all uses of temporary and short ConstStrings in LLDB to use this new
comparison operator. It also adds a some unit tests for the new and old comparison operator.
Reviewers: #lldb, JDevlieghere, espindola, amccarth
Reviewed By: JDevlieghere, amccarth
Subscribers: amccarth, clayborg, JDevlieghere, emaste, arichardson, MaskRay, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D60667
llvm-svn: 359281
Use constexpr to explicitly indicate that we're dealing with integer
constants, and provoke clang to assign them straight to registers
whenever possible. Adjust input constraints in %mmN tests to "rm"
as using integer constants is apparently disallowed there. Also
use "i" for %rN tests, as we don't want clang to accidentally clobber
those general purpose registers while assigning to them (however
unlikely that is).
llvm-svn: 359228
Add tests covering read operations for the general-purpose and XMM
registers added in x86_64 (r8-r15 and xmm8-xmm15).
Differential Revision: https://reviews.llvm.org/D61072
llvm-svn: 359210
Remove the use of 2-element array for XMM data. It is an accidental
leftover from previous implementation attempt, and it is unnecessary
with xmm_t.
Differential Revision: https://reviews.llvm.org/D61085
llvm-svn: 359208
Under very specific circumstances the default shell /bin/sh might
print stuff to stderr before launching lldb-argdumper, which then
confuses the JSON parser. This patch suppresses stderr output from
lldb-argdumper to avoid this situation.
rdar://problem/50149390
Differential Revision: https://reviews.llvm.org/D61101
llvm-svn: 359156
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 is needed for gcc/cstdlib++ 5.4.0, where __get_cpuid_count is not
defined in cpuid.h.
Reviewers: labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D61036
llvm-svn: 359120
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:
After the last round of cleanups, this script was almost a no-op. The
only piece of functionality that remained was the one which tried to
make the swig-generated function signatures more pythonic.
The "tried" part is important here, as it wasn't doing a really good job
and the end result was not valid python nor c (e.g.,
SetExecutable(SBAttachInfo self, str const * path)).
Doing these transformations another way is not possible, as these
signatures are generated by swig, and not present in source. However,
given that this is the only reason why we need a swig post-process step,
and that the current implementation is pretty sub-optimal, this patch
simply abandons the signature fixup idea, and chooses to simplify our
build process instead.
Reviewers: amccarth, jingham, clayborg
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D61000
llvm-svn: 359092
Summary:
The postfix expressions in PDB and breakpad symbol files are similar
enough that they can be parsed by the same parser. This patch
generalizes the parser in the NativePDB plugin and moves it into the
PostfixExpression file created in the previous commit (r358976).
The generalization consists of treating any unrecognised token as a
"symbol" node (previously these would only be created for tokens
starting with "$", and other token would abort the parse). This is
needed because breakpad symbols can also contain ".cfa" tokens, which
refer to the frame's CFA.
The cosmetic changes include:
- using a factory function instead of a class for creating nodes (this
is more generic as it allows the same BumpPtrAllocator to be used for
other things too)
- using dedicated function for parsing operator tokens instead of a
DenseMap (more efficient as we don't need to create the DenseMap every
time).
Reviewers: amccarth, clayborg, JDevlieghere, aleksandr.urakov
Subscribers: jasonmolenda, lldb-commits, markmentovai, mgorny
Differential Revision: https://reviews.llvm.org/D61003
llvm-svn: 359073
Before a Debugger gets a Target, target settings are routed to a global set
of settings. Even without this, some part of the LLDB which exist independently
of the Debugger object (the Module cache, the Symbol vendors, ...) access
directly the global default store for those settings.
Of course, if you modify one of those global settings while they are being read,
bad things happen. We see this quite a bit with FileSpecList settings. In
particular, we see many cases where one debug session changes
target.exec-search-paths while another session starts up and it crashes when
one of those accesses invalid FileSpecs.
This patch addresses the specific FileSpecList issue by adding locking to
OptionValueFileSpecList and never returning by reference.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D60468
llvm-svn: 359028
We recently moved API logging into the instrumentation macros. This made
that logging is now consistent and abstracted behind a macro for every
API functions, independent of the reproducers. It also means we have a
lot more output. While this is a good thing, it also meant a lot more
noise in the log, from things that aren't always equally interesting,
such as the copy constructor for example.
To improve usability, we should increase the signal-to-noise ratio. I
propose to achieve this by only logging API functions that cross the API
boundary. This is a divergence of what we had before, where a select
number of functions were logged, irregardless of the API boundary, a
concept that was introduced for the reproducers. However, I believe this
is in line with the purpose of the API log.
Differential revision: https://reviews.llvm.org/D60984
llvm-svn: 359016
Summary:
The NativePDB plugin contains code to convert "programs" describing the
layout of function frames into dwarf (for easier interaction with the
rest of lldb). This functionality is useful for the Breakpad plugin too,
as it contains the same kind of expressions (because breakpad info is
generated from pdb files).
In this patch, I move the core classes of this code into a common place,
where it can be used from both files. Previously, these were the details
of the implementation, but here I am exposing them (instead of just a
single "string->string" conversion function), as breakpad will need to
use these in a slightly different way. The reason for that is that
breakpad files generated from dwarf expressions use a slightly different
syntax, although most of the core code can be reused with a bit of
thought.
This is also the reason why I am not moving the parsing or dwarf
generation bits, as they will need to be generalized a bit before
they're usable for both scenarios.
This patch should be NFC, modulo renaming the moved entities to more
neutral names.
The reason I am moving this to the "Symbol" library, is because both
customers will be "Symbol"Files, and also the unwinding code lives in
the Symbol library. From a purely dependency standpoint this code will
probably be standalone, and so it could be moved all the way to Utility,
but that seems too low for this kind of functionality.
Reviewers: jasonmolenda, amccarth, clayborg, JDevlieghere, aleksandr.urakov
Subscribers: aprantl, markmentovai, lldb-commits
Differential Revision: https://reviews.llvm.org/D60599
llvm-svn: 358976
Summary:
This argument was added back in 2010 (r118882) to support the ability to unwind
from functions whose eh_frame entry does not cover the entire range of
the function.
However, due to the caching happening in FuncUnwinders, this solution is
very fragile. FuncUnwinders will cache the plan it got from eh_frame
regardless of the value of the current_offset, so our ability to unwind
from a given function depended what was the value of "current_offset" the
first time that this function was called.
Furthermore, since the "image show-unwind" command did not know what's
the right offset to pass, this created an unfortunate situation where
"image show-unwind" would show no valid plans for a function, even
though they were available and being used.
In this patch I implement the feature slightly differently. Instead of
giving just a base address to the eh_frame unwinder, I give it the
entire range we are interested in. Then, I change the unwinder to return
the first plan that covers (even partially) that range. This way even a
partial plan will be returned, regardless of the address in the function
where we are stopped at.
This solution is still not 100% correct, as it will not handle a
function which is covered by two independent fde entries. However, I
don't expect anybody will write this kind of functions, and this wasn't
handled by the previous implementation either. If this is ever needed in
the future. The eh_frame unwinder can be extended to return "composite"
unwind plans created by merging sevelar fde entries.
I also create a test which triggers this scenario. As doing this is
virtually impossible without hand-written assembly, the test only works
on x86 linux.
Reviewers: jasonmolenda, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D60829
llvm-svn: 358964
Summary:
Previously we were printing the dwarf expressions in unwind rules simply
as "dwarf-expr". This patch uses the existing dwarf-printing
capabilities in lldb to enhance this dump output, and print the full
decoded dwarf expression.
Reviewers: jasonmolenda, clayborg
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D60949
llvm-svn: 358959
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
was still stat'ing the possibly-dSYM FileSpec before I
(more cheaply) checked the filepath for telltale dSYM
components.
<rdar://problem/50086007>
llvm-svn: 358939
which reads the python files in a dSYM bundle, to check that the
SymbolFile is actually a dSYM bundle filepath; delay any fetching
of the ScriptInterpreter until after we've done that check.
When debugging a binary without a dSYM on darwin systems, the
SymbolFile we fetch is actually the ObjectFile -- so we would do
an unnecessary trip into Python land and stat around the filesystem
looking for a python file to read in. There's no reason to do any
of this unless the SymbolFile's file path includes the .dSYM bundle
telltale path components.
<rdar://problem/50065315>
llvm-svn: 358938
In the process of hoisting the LoadScriptingResourceForModule
out of Target::ModuleAdded and into Target::ModulesDidLoad,
I had ModulesDidLoad fetching the Target's entire image list
and look for scripting resources in those -- instead of only
looking for scripting resources in the modules that had
been added to the target's image list.
<rdar://problem/50065315>
llvm-svn: 358929
This moves the links to the C++ and Python API docs up to the main page.
As of now the links are still broken [1], but at least this will prevent
the additional frustration of searching for the links only to find out
they're broken.
[1] http://lists.llvm.org/pipermail/lldb-dev/2019-April/014992.html
llvm-svn: 358928
Deallocating the data recorder in during the ::Keep() operation causes
problems down the line when exiting the debugger. The command
interpreter still holds a pointer to the now deallocated object and has
no way to know it no longer exists. This is exactly what the m_record
flag was meant for, although it wasn't hooked up properly either.
llvm-svn: 358916
Stefan Granitz