debug_frame does not seem to work on darwin, so there is nothing to
prefer.
Adding `-g` to the compiler command line is enough to get the
__debug_frame section added to the dsym file. Though lldb then finds the
section, and correctly assigns the section type to it, this does not
seem to be enough to get lldb to actually use this section for
unwinding.
llvm-svn: 361760
The two sections usually contain the same information, and we rarely
have both kinds of entries for a single function. However, in theory the
debug_frame plan can be more complete, whereas eh_frame is only required
to be correct at places where exceptions can be thrown.
Reviewers: jasonmolenda, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D62374
llvm-svn: 361758
Summary:
Previous patch (r360409) introduced the "symbol file unwind plan"
concept, but that plan wasn't used for unwinding yet. With this patch,
we start to consider the new plan as a possible strategy for both
synchronous and asynchronous unwinding. I also add a test that asserts
that unwinding via breakpad STACK CFI info works end-to-end.
Reviewers: jasonmolenda, clayborg
Subscribers: lldb-commits, amccarth, markmentovai
Differential Revision: https://reviews.llvm.org/D61853
llvm-svn: 361618
Summary:
This patch implements the main feature of type units. When completing a
type, if we encounter a DW_AT_signature attribute, we use it's value to
lookup the complete definition of the type in the relevant type unit.
To enable this lookup, we build up a map of all type units in a symbol
file when parsing the units. Then we consult this map when resolving the
DW_AT_signature attribute.
I include add a couple of tests which exercise the type lookup feature,
including one that ensure we do something reasonable in case we fail to
lookup the type.
A lot of the ideas in this patch have been taken from D32167 and D61505.
Reviewers: clayborg, JDevlieghere, aprantl, alexshap
Subscribers: mgrang, lldb-commits
Differential Revision: https://reviews.llvm.org/D62246
llvm-svn: 361603
Summary:
SymbolFileDWARF used to load debug sections in a thread-safe manner.
When we moved to DWARFContext, we dropped the thread-safe part, because
we thought it was not necessary.
It turns out this was only mostly correct.
The "mostly" part is there because this is a problem only if we use the
manual index, as that is the only source of intra-module paralelism.
Also, this only seems to occur for extremely simple files (like the ones
I've been creating for tests lately), where we've managed to start
indexing before loading the debug_str section. Then, two threads start
to load the section simultaneously and produce wrong results.
On more complex files, something seems to be loading the debug_str section
before we start indexing, as I haven't been able to reproduce this
there, but I have not investigated what it is.
I've tried to come up with a test for this, but I haven't been able to
reproduce the problem reliably. Still, while doing so, I created a way
to generate many compile units on demand. Given that most of our tests
work with only one or two compile units, it seems like this could be
useful anyway.
Reviewers: aprantl, JDevlieghere, clayborg
Subscribers: arphaman, lldb-commits
Differential Revision: https://reviews.llvm.org/D62316
llvm-svn: 361602
Summary:
Type units don't describe any code, so they should never be the result
of any address lookup queries.
Previously, we would compute the address ranges for the type units for
via the line tables they reference because the type units looked a lot
like line-tables-only compile units. However, this is not correct, as
the line tables are only referenced from type units so that other
declarations can use the file names contained in them.
In this patch I make the BuildAddressRangeTable function virtual, and
implement it only for compile units.
Testing this was a bit tricky, because the behavior depends on the order
in which we add things to the address range map. This rarely caused a
problem with DWARF v4 type units, as they are always added after all
CUs. It happened more frequently with DWARF v5, as there clang emits the
type units first. However, this is still not something that it is
required to do, so for testing I've created an assembly file where I've
deliberately sandwiched a compile unit between two type units, which
should isolate us from both changes in how the compiler emits the units
and changes in the order we process them.
Reviewers: clayborg, aprantl, JDevlieghere
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D62178
llvm-svn: 361465
.debug_ranges parsing is not well tested [citation needed] because this
section tends to be only used in optimized code, and we don't build
optimized executables in our tests, as they produce unpredictable
results.
This patch aims to add some very simple tests for parsing static range
data, which can serve as a first line of defense in case things break.
I also include one XFAILed test, which demonstrates that we don't
correctly handle mixed DWARF v5 and v4 ranges in a single file.
llvm-svn: 361373
Summary:
This patch introduces the DWARFTypeUnit class, and teaches lldb to parse
type units out of both the debug_types section (DWARF v4), and from the
regular debug_info section (DWARF v5).
The most important piece of functionality - resolving DW_AT_signatures
to connect type forward declarations to their definitions - is not
implemented here, but even without that, a lot of functionality becomes
available. I've added tests for the commands that start to work after
this patch.
The changes in this patch were greatly inspired by D61505, which in turn took
over changes from D32167.
Reviewers: JDevlieghere, clayborg, aprantl
Subscribers: mgorny, jankratochvil, lldb-commits
Differential Revision: https://reviews.llvm.org/D62008
llvm-svn: 361360
LocalLLDBInit.test requires Python module loading support.
CommandScriptImmediateOutput tests are specific to running scripts.
Disable all of them when Python support is disabled.
llvm-svn: 361115
The change that was committed for this used \\s to match spaces which does not work correctly on all platforms. Using [:space:] makes the test pass on both Linux and Windows
llvm-svn: 361064
Previously "bt all " would've failed as the regex didn't match
them.
Over the shoulder review by Jonas Devlieghere.
<rdar://problem/50824935>
llvm-svn: 360966
Summary:
There are several reasons for doing this:
- generally, there's no reason to differentiate between a section being
absent and it being present, but empty
- it matches more closely what llvm DWARF parser is doing (which also
doesn't differentiate the two cases)
- SymbolFileDWARF also doesn't differentiate the two cases, which makes
porting the rest of sections easier
- it fixes a bug in how the return-null-if-empty logic was implemented
(it returned nullptr only the second time we tried to get the
debug_aranges section), which meant that we hit an assert when trying
to parse an empty-but-present section
Reviewers: JDevlieghere, clayborg, aprantl
Subscribers: zturner, lldb-commits
Differential Revision: https://reviews.llvm.org/D61942
llvm-svn: 360874
Summary:
This patch adds the ability to precisely address debug info in
situations when a single file can have more than one debug-info-bearing
sections (as is the case with type units in DWARF v4).
The changes here can be classified into roughly three categories:
- the code which addresses a debug info by offset gets an additional
argument, which specifies the section one should look into.
- the DIERef class also gets an additional member variable specifying
the section. This way, code dealing with DIERefs can know which
section is the object referring to.
- the user_id_t encoding steals one bit from the dwarf_id field to store
the section. This means the total number of separate object files
(apple .o, or normal .dwo) is limited to 2 billion, but that is fine
as it's not possible to hit that number without switching to DWARF64
anyway.
This patch is functionally equivalent to (and inspired by) the two
patches (D61503 and D61504) by Jan Kratochvil, but there are differences
in the implementation:
- it uses an enum instead of a bool flag to differentiate the sections
- it increases the size of DIERef struct instead of reducing the amount
of addressable debug info
- it sets up DWARFDebugInfo to store the units in a single vector
instead of two. This sets us up for the future in which type units can
also live in the debug_info section, and I believe it's cleaner
because there's no need for unit index remapping
There are no tests with this patch as this is essentially NFC until
we start parsing type units from the debug_types section.
Reviewers: JDevlieghere, clayborg, aprantl
Subscribers: arphaman, jankratochvil, lldb-commits
Differential Revision: https://reviews.llvm.org/D61908
llvm-svn: 360872
Pass '--mode=compile' to fix compiler-full-path.test failure on NetBSD
buildbot (apparently due to lack of 'link' executable).
Fixes r360355. Acked by Pavel Labath.
llvm-svn: 360761
The input source file seems to be triggering an error in the Visual
Studio headers.
> xstddef:338:2: error: ''auto' return without trailing return type;
> deduced return types are a C++14 extension
I tried converting the test to use the %build stuff Zachary added, but
that seems to be missing some Darwin support. Disabling the test on
Windows in the meantime.
llvm-svn: 360624
Before this change we were overriding the launch info environment with
the target environment. This meant that the environment variables passed
to `process launch --environment <>` were lost. Instead of replacing the
environment, we should merge them.
Differential revision: https://reviews.llvm.org/D61864
llvm-svn: 360612
Summary:
This patch implements the GetUnwindPlan interface (added in the previous
patch) for SymbolFileBreakpad, and uses it to generate unwind plans from
STACK CFI records in breakpad files.
We first perform a light-weight parse of the breakpad in order to build
up a map of regions covered by the unwind info so that we can later jump
to the right record when we need to unwind a specific function.
The actual parsing is relatively straight-forward, as the STACK CFI records
are just another (text) form of the eh_frame unwind instructions, and
the same goes for lldb's UnwindPlans. The newly-introduced
PostfixExpression API is used to convert the breakpad postfix
expressions into DWARF. The generated dwarf expressions are stored in a
BumpPtrAllocator, as the UnwindPlan does not take ownership of the
expression data it references (usually this is static data in an object
file, so special ownership is needed).
At this moment the generated unwind plans aren't used in the actual
unwind machinery (only in the image show-unwind command), but that is
coming in a separate patch.
Reviewers: amccarth, clayborg, markmentovai
Subscribers: aprantl, jasonmolenda, lldb-commits
Differential Revision: https://reviews.llvm.org/D61733
llvm-svn: 360574
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
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
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
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
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
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
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
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
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
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
Stefan Granitz