Summary:
The first section header does not define a real section. Instead it is
used for various elf extensions. This patch skips creation of a section
for index 0.
This has one furtunate side-effect, in that it allows us to use the section
header index as the Section ID (where 0 is also invalid). This way, we
can get rid of a lot of spurious +1s in the ObjectFileELF code.
Reviewers: clayborg, krytarowski, joerg, espindola
Subscribers: emaste, lldb-commits, arichardson
Differential Revision: https://reviews.llvm.org/D55757
llvm-svn: 349498
Summary:
Previously lldb-test's LinePrinter would output the indentation spaces
even on completely empty lines. This is not nice, as trailing spaces get
flagged as errors in some tools/editors, and it prevents FileCheck's
CHECK-EMPTY from working.
Equally annoying was the fact that the LinePrinter did not terminate
it's output with a newline (instead it would leave the unterminated hanging
indent from the last NewLine() command), which meant that the shell prompt
following the lldb-test command came out wrong.
This fixes both issues by changing how newlines are handled. NewLine(),
which was ending the previous line ('\n') *and* begging the next line by
printing the indent, is now "demoted" to just printing literal "\n".
Instead, lines are now delimited via a helper Line object, which makes
sure the line is indented and terminated in an RAII fashion. The typical
usage would be:
Printer.line() << "This text will be indented and terminated";
If one needs to do more work than it will fit into a single statement,
one can also assign the result of the line() function to a local
variable. The line will then be terminated when that object goes out of
scope.
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D55597
llvm-svn: 349269
Summary:
This patch attempts to move as much code as possible out of the
CreateSections function to make room for future improvements there. Some
of this may be slightly over-engineered (VMAddressProvider), but I
wanted to keep the logic of this function very simple, because once I
start taking segment headers into acount (as discussed in D55356), the
function is going to grow significantly.
While in there, I also added tests for various bits of functionality.
This should be NFC, except that I changed the order of hac^H^Heuristicks
for determining section type slightly. Previously, name-based deduction
(.symtab -> symtab) would take precedence over type-based (SHT_SYMTAB ->
symtab) one. In fact we would assert if we ran into a .text section with
type SHT_SYMTAB. Though unlikely to matter in practice, this order
seemed wrong to me, so I have inverted it.
Reviewers: clayborg, krytarowski, espindola
Subscribers: emaste, arichardson, lldb-commits
Differential Revision: https://reviews.llvm.org/D55706
llvm-svn: 349268
We've recently developed a convention where the tests are placed into
subfolders according to the object file type. This applies that
convention to existing tests too.
llvm-svn: 349027
Move code into a separate function, and replace the if-else chain with
llvm::StringSwitch.
A slight behavioral change is that now I use the section flags
(SHF_TLS) instead of the section name to set the thread-specific
property. There is no explanation in the original commit introducing
this (r153537) as to why that was done this way, but the new behavior
should be more correct.
llvm-svn: 348936
Previously, lldb-test would only print top-level sections. However, in
lldb, sections can contain other sections. This teaches lldb-test to
print nested sections too.
llvm-svn: 348924
This re-commits r348592, which was reverted due to a failing test on
macos.
The issue was that I was passing a null pointer for the
"CreateMemoryInstance" callback when registering ObjectFileBreakpad,
which caused crashes when attemping to load modules from memory. The
correct thing to do is to pass a callback which always returns a null
pointer (as breakpad files are never loaded in inferior memory).
It turns out that there is only one test which exercises this code path,
and it's mac-only, so I've create a new test which should run everywhere
(except windows, as one cannot delete an executable which is being run).
Unfortunately, this test still fails on linux for other reasons, but at
least it gives us something to aim for.
The original commit message was:
This patch adds the scaffolding necessary for lldb to recognise symbol
files generated by breakpad. These (textual) files contain just enough
information to be able to produce a backtrace from a crash
dump. This information includes:
- UUID, architecture and name of the module
- line tables
- list of symbols
- unwind information
A minimal breakpad file could look like this:
MODULE Linux x86_64 0000000024B5D199F0F766FFFFFF5DC30 a.out
INFO CODE_ID 00000000B52499D1F0F766FFFFFF5DC3
FILE 0 /tmp/a.c
FUNC 1010 10 0 _start
1010 4 4 0
1014 5 5 0
1019 5 6 0
101e 2 7 0
PUBLIC 1010 0 _start
STACK CFI INIT 1010 10 .cfa: $rsp 8 + .ra: .cfa -8 + ^
STACK CFI 1011 $rbp: .cfa -16 + ^ .cfa: $rsp 16 +
STACK CFI 1014 .cfa: $rbp 16 +
Even though this data would normally be considered "symbol" information,
in the current lldb infrastructure it is assumed every SymbolFile object
is backed by an ObjectFile instance. So, in order to better interoperate
with the rest of the code (particularly symbol vendors).
In this patch I just parse the breakpad header, which is enough to
populate the UUID and architecture fields of the ObjectFile interface.
The rough plan for followup patches is to expose the individual parts of
the breakpad file as ObjectFile "sections", which can then be used by
other parts of the codebase (SymbolFileBreakpad ?) to vend the necessary
information.
Reviewers: clayborg, zturner, lemo, amccarth
Subscribers: mgorny, fedor.sergeev, markmentovai, lldb-commits
Differential Revision: https://reviews.llvm.org/D55214
llvm-svn: 348773
Summary:
This patch adds the scaffolding necessary for lldb to recognise symbol
files generated by breakpad. These (textual) files contain just enough
information to be able to produce a backtrace from a crash
dump. This information includes:
- UUID, architecture and name of the module
- line tables
- list of symbols
- unwind information
A minimal breakpad file could look like this:
MODULE Linux x86_64 0000000024B5D199F0F766FFFFFF5DC30 a.out
INFO CODE_ID 00000000B52499D1F0F766FFFFFF5DC3
FILE 0 /tmp/a.c
FUNC 1010 10 0 _start
1010 4 4 0
1014 5 5 0
1019 5 6 0
101e 2 7 0
PUBLIC 1010 0 _start
STACK CFI INIT 1010 10 .cfa: $rsp 8 + .ra: .cfa -8 + ^
STACK CFI 1011 $rbp: .cfa -16 + ^ .cfa: $rsp 16 +
STACK CFI 1014 .cfa: $rbp 16 +
Even though this data would normally be considered "symbol" information,
in the current lldb infrastructure it is assumed every SymbolFile object
is backed by an ObjectFile instance. So, in order to better interoperate
with the rest of the code (particularly symbol vendors).
In this patch I just parse the breakpad header, which is enough to
populate the UUID and architecture fields of the ObjectFile interface.
The rough plan for followup patches is to expose the individual parts of
the breakpad file as ObjectFile "sections", which can then be used by
other parts of the codebase (SymbolFileBreakpad ?) to vend the necessary
information.
Reviewers: clayborg, zturner, lemo, amccarth
Subscribers: mgorny, fedor.sergeev, markmentovai, lldb-commits
Differential Revision: https://reviews.llvm.org/D55214
llvm-svn: 348592
Summary:
This parses entries in pecoff import tables for imported DLLs and
is intended as the first step to allow LLDB to load a PE's shared
modules when creating a target on the LLDB console.
Reviewers: rnk, zturner, aleksandr.urakov, lldb-commits, labath, asmith
Reviewed By: labath, asmith
Subscribers: labath, lemo, clayborg, Hui, mgorny, mgrang, teemperor
Differential Revision: https://reviews.llvm.org/D53094
llvm-svn: 348527
LC_BUILD_VERSION records are of variable length. The original code
would use uninitialized memory when the size of a record was exactly 24.
rdar://problem/46032185
llvm-svn: 346812
LC_BUILD_VERSION load command handling - this
commit is a combination of patches by Adrian
Prantl and myself. llvm::Triple::BridgeOS
isn't defined yet, so all references to that
are currently commented out.
Also update Xcode project file to build the
NativePDB etc plugins.
<rdar://problem/43353615>
llvm-svn: 344209
This change improves the logging for the lldb.module category to note a few interesting cases:
1. Local object file found, but specs not matching
2. Local object file not found, using a placeholder module
The handling and logging for the cases wehre we fail to load compressed dwarf
symbols is also improved.
Differential Revision: https://reviews.llvm.org/D50274
llvm-svn: 339161
The new test checks that we are actually able to read data from these
kinds of elf headers correctly instead of just that we read the section
number correctly. It is also easier to figure out what's going on in the
test.
llvm-svn: 337459
Summary:
This test makes sure we are able to read the shorter build-ids which are
generated by lld.
To make this work, I've extended lldb-test to print the UUID of the
loaded object file. I've renamed the lldb-test subcommand from
"module-sections" to "object-file" to reflect the fact it prints more
than just the sections.
I've also added the module Architecture to the output, so we could avoid
printing the entire symbol file information just to get the ArchSpec
details in the lc_version_min test (which was also the only test in it's
folder not using the module-sections command).
Reviewers: aprantl, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D48646
llvm-svn: 335967
Summary:
Before this patch we were unable to write cross-platform MachO tests
because the parsing code did not compile on other platforms. The reason
for that was that ObjectFileMachO depended on
RegisterContextDarwin_arm(64)? (presumably for core file parsing) and
the two Register Context classes uses constants from the system headers
(KERN_SUCCESS, KERN_INVALID_ARGUMENT).
As far as I can tell, these two files don't actually interact with the
darwin kernel -- they are used only in ObjectFileMachO and MacOSX-Kernel
process plugin (even though it has "kernel" in the name, this one
communicates with it via network packets and not syscalls). For the time
being I have created OS-independent definitions of these constants and
made the register context classes use those. Long term, the error
handling in these classes should be probably changed to use more
standard mechanisms such as Status or Error classes.
This is the only change necessary (apart from build system glue) to make
ObjectFileMachO work on other platforms. To demonstrate that, I remove
REQUIRES:darwin from our (only) cross-platform mach-o test.
Reviewers: jasonmolenda, aprantl, clayborg, javed.absar
Subscribers: mgorny, lldb-commits, kristof.beyls
Differential Revision: https://reviews.llvm.org/D46934
llvm-svn: 332702
Getting the deployment target can be significant information when
rebuilding clang modules since availability information could depend
on it.
rdar://problem/40039633
Differential Revision: https://reviews.llvm.org/D46669
llvm-svn: 332067
In an effort to make the .debug_types patch smaller, breaking out the part that reads the .debug_types from object files into a separate patch
Differential Revision: https://reviews.llvm.org/D46529
llvm-svn: 331777
ObjectFileELF assumes that code section has ".text" name. There is an
exception for kalimba toolchain that can use arbitrary names, but other
toolchains also could use arbitrary names for code sections. For
example, corert uses separate section for compiled managed code. As lldb
doesn't recognize such section it leads to problem with breakpoints on
arm, because debugger cannot determine instruction set (arm/thumb) and
uses incorrect breakpoint opcode that breaks program execution.
This change allows debugger to correctly handle such code sections. We
assume that section is a code section if it has SHF_EXECINSTR flag set
and has SHT_PROGBITS type.
Patch by Konstantin Baladurin <k.baladurin@partner.samsung.com>.
Differential Revision: https://reviews.llvm.org/D44998
llvm-svn: 331173
Summary:
Besides being superfluous, this double merging was actually wrong and
causing some sections to be added twice. The reason for that was that
the code assumes section IDs are unique in the section list, but this is
only true if all sections in the list come from the same object file.
Reviewers: fjricci, jankratochvil
Subscribers: emaste, lldb-commits, arichardson
Differential Revision: https://reviews.llvm.org/D44157
llvm-svn: 327123
Summary:
The test was failing in remote debugging scenario with windows as a host
as cmd.exe is not able to parse the complicated shell commands in the
Makefile.
The test seemed like a perfect candidate for a more focused testing
approach, so I have rewritten in on top of lldb-test's module-sections
functionality. The slight gotcha there was that the
Module::GetSectionList does not include the sections from the symbol
file until someone manually calls Module::GetSymbolVendor. Normally,
this is not an issue, because someone will have initialized the symbol
vendor by the time anyone starts looking at the sections. However, when
all one this is dump the section list, we run into this problem.
I've tried making this behavior more automatic, but it turns out it's
not that easy, so for now, I just manually initialize the Symbol Vendor
before dumping out the sections in lldb-test.
Reviewers: jankratochvil
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D42914
llvm-svn: 326805
Summary:
We use the llvm decompressor to decompress SHF_COMPRESSED sections. This enables
us to read data from debug info sections, which are sometimes compressed,
particuarly in the split-dwarf case. This functionality is only available if
llvm is compiled with zlib support.
Reviewers: clayborg, zturner
Subscribers: emaste, mgorny, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D40616
llvm-svn: 320813
Pavel Labath