[lldb/Module] Allow for the creation of memory-only modules

Summary:
This patch extends the ModuleSpec class to include a
DataBufferSP which contains the module data. If this
data is provided, LLDB

[lldb/Module] Allow for the creation of memory-only modules

Summary:
This patch extends the ModuleSpec class to include a
DataBufferSP which contains the module data. If this
data is provided, LLDB won't try to hit the filesystem
to create the Module, but use only the data stored in
the ModuleSpec.

Reviewers: labath, espindola

Subscribers: emaste, MaskRay, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D83512

show more ...

[lldb] Use std::make_unique<> (NFC)

Update the rest of lldb to use std::make_unique<>. I used clang-tidy to
automate this, which probably missed cases that are wrapped in ifdefs.

[lldb] Switch Section-dumping code to raw_ostream

Also, add a basic test for dumping sections.

[lldb] NFC: Fix trivial typo in comments, documents, and messages

Differential Revision: https://reviews.llvm.org/D77460

[RISCV] ELF attribute section for RISC-V.

Leverage ARM ELF build attribute section to create ELF attribute section
for RISC-V. Extract the common part of parsing logic for this section
into ELFAttri

[RISCV] ELF attribute section for RISC-V.

Leverage ARM ELF build attribute section to create ELF attribute section
for RISC-V. Extract the common part of parsing logic for this section
into ELFAttributeParser.[cpp|h] and ELFAttributes.[cpp|h].

Differential Revision: https://reviews.llvm.org/D74023

show more ...

[lldb] Add boilerplate to recognize the .debug_tu_index section

It's just like debug_cu_index, only for type units.

[lldb/Plugin] s/LLDB_PLUGIN/LLDB_PLUGIN_DEFINE/ (NFC)

Rename LLDB_PLUGIN to LLDB_PLUGIN_DEFINE as Pavel suggested in D73067 to
avoid name conflict.

[LLDB] Fix GCC warnings about extra semicolons. NFC.

[lldb/Plugins] Use external functions to (de)initialize plugins

This is a step towards making the initialize and terminate calls be
generated by CMake, which in turn is towards making it possible to

[lldb/Plugins] Use external functions to (de)initialize plugins

This is a step towards making the initialize and terminate calls be
generated by CMake, which in turn is towards making it possible to
disable plugins at configuration time.

Differential revision: https://reviews.llvm.org/D74245

show more ...

[lldb] [ObjectFile/ELF] Fix negated seg ids on 32-bit arches

Scale segment identifier up to user_id_t before negating it. This fixes
the identifers being wrongly e.g. 0x00000000fffffffe instead of

[lldb] [ObjectFile/ELF] Fix negated seg ids on 32-bit arches

Scale segment identifier up to user_id_t before negating it. This fixes
the identifers being wrongly e.g. 0x00000000fffffffe instead of
0xfffffffffffffffe. Fix suggested by Pavel Labath.

This fixes 5 tests failing on i386 (PR #44748):

lldb-shell :: ObjectFile/ELF/PT_LOAD-overlap-PT_INTERP.yaml
lldb-shell :: ObjectFile/ELF/PT_LOAD-overlap-PT_TLS.yaml
lldb-shell :: ObjectFile/ELF/PT_LOAD-overlap-section.yaml
lldb-shell :: ObjectFile/ELF/PT_LOAD.yaml
lldb-shell :: ObjectFile/ELF/PT_TLS-overlap-PT_LOAD.yaml

Differential Revision: https://reviews.llvm.org/D73914

show more ...

[lldb][NFCI] Remove unused LanguageType parameters

These parameters are unused in these methods, and some of them only had a
LanguageType parameter to pipe to other methods that don't use it
either.

Make llvm::StringRef to std::string conversions explicit.

This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly m

Make llvm::StringRef to std::string conversions explicit.

This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.

This doesn't actually modify StringRef yet, I'll do that in a follow-up.

show more ...

[lldb][NFC] Fix all formatting errors in .cpp file headers

Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp ----------------------------------------

[lldb][NFC] Fix all formatting errors in .cpp file headers

Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp -------------------------------------------------===//
```
However in LLDB most of our source files have arbitrary changes to this format and
these changes are spreading through LLDB as folks usually just use the existing
source files as templates for their new files (most notably the unnecessary
editor language indicator `-*- C++ -*-` is spreading and in every review
someone is pointing out that this is wrong, resulting in people pointing out that this
is done in the same way in other files).

This patch removes most of these inconsistencies including the editor language indicators,
all the different missing/additional '-' characters, files that center the file name, missing
trailing `===//` (mostly caused by clang-format breaking the line).

Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere

Reviewed By: JDevlieghere

Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D73258

show more ...

[lldb/DWARF] Move location list sections into DWARFContext

These are the last sections not managed by the DWARFContext object. I
also introduce separate SectionType enums for dwo section variants, a

[lldb/DWARF] Move location list sections into DWARFContext

These are the last sections not managed by the DWARFContext object. I
also introduce separate SectionType enums for dwo section variants, as
this is necessary for proper handling of single-file split dwarf.

show more ...

[lldb] Fix lookup of symbols with the same address range but different binding

This fixes a failing testcase on Fedora 30 x86_64 (regression Fedora 29->30):

PASS:
./bin/lldb ./lldb-test-build.noind

[lldb] Fix lookup of symbols with the same address range but different binding

This fixes a failing testcase on Fedora 30 x86_64 (regression Fedora 29->30):

PASS:
./bin/lldb ./lldb-test-build.noindex/functionalities/unwind/noreturn/TestNoreturnUnwind.test_dwarf/a.out -o 'settings set symbols.enable-external-lookup false' -o r -o bt -o quit
* frame #0: 0x00007ffff7aa6e75 libc.so.6`__GI_raise + 325
frame #1: 0x00007ffff7a91895 libc.so.6`__GI_abort + 295
frame #2: 0x0000000000401140 a.out`func_c at main.c:12:2
frame #3: 0x000000000040113a a.out`func_b at main.c:18:2
frame #4: 0x0000000000401134 a.out`func_a at main.c:26:2
frame #5: 0x000000000040112e a.out`main(argc=<unavailable>, argv=<unavailable>) at main.c:32:2
frame #6: 0x00007ffff7a92f33 libc.so.6`__libc_start_main + 243
frame #7: 0x000000000040106e a.out`_start + 46

vs.

FAIL - unrecognized abort() function:
./bin/lldb ./lldb-test-build.noindex/functionalities/unwind/noreturn/TestNoreturnUnwind.test_dwarf/a.out -o 'settings set symbols.enable-external-lookup false' -o r -o bt -o quit
* frame #0: 0x00007ffff7aa6e75 libc.so.6`.annobin_raise.c + 325
frame #1: 0x00007ffff7a91895 libc.so.6`.annobin_loadmsgcat.c_end.unlikely + 295
frame #2: 0x0000000000401140 a.out`func_c at main.c:12:2
frame #3: 0x000000000040113a a.out`func_b at main.c:18:2
frame #4: 0x0000000000401134 a.out`func_a at main.c:26:2
frame #5: 0x000000000040112e a.out`main(argc=<unavailable>, argv=<unavailable>) at main.c:32:2
frame #6: 0x00007ffff7a92f33 libc.so.6`.annobin_libc_start.c + 243
frame #7: 0x000000000040106e a.out`.annobin_init.c.hot + 46

The extra ELF symbols are there due to Annobin (I did not investigate why this
problem happened specifically since F-30 and not since F-28).

It is due to:

Symbol table '.dynsym' contains 2361 entries:
Valu e Size Type Bind Vis Name
0000000000022769 5 FUNC LOCAL DEFAULT _nl_load_domain.cold
000000000002276e 0 NOTYPE LOCAL HIDDEN .annobin_abort.c.unlikely
...
000000000002276e 0 NOTYPE LOCAL HIDDEN .annobin_loadmsgcat.c_end.unlikely
...
000000000002276e 0 NOTYPE LOCAL HIDDEN .annobin_textdomain.c_end.unlikely
000000000002276e 548 FUNC GLOBAL DEFAULT abort
000000000002276e 548 FUNC GLOBAL DEFAULT abort@@GLIBC_2.2.5
000000000002276e 548 FUNC LOCAL DEFAULT __GI_abort
0000000000022992 0 NOTYPE LOCAL HIDDEN .annobin_abort.c_end.unlikely

GDB has some more complicated preferences between overlapping and/or sharing
address symbols, I have made here so far the most simple fix for this case.

Differential revision: https://reviews.llvm.org/D63540

show more ...

[lldb] Add boilerplate to recognize the .debug_rnglists.dwo section

Remove obsolete parameter.

llvm-svn: 374185

Remove the is_mangled flag from Mangled and Symbol

Testing whether a name is mangled or not is extremely cheap and can be
done by looking at the first two characters. Mangled knows how to do
it. On

Remove the is_mangled flag from Mangled and Symbol

Testing whether a name is mangled or not is extremely cheap and can be
done by looking at the first two characters. Mangled knows how to do
it. On the flip side, many call sites that currently pass in an
is_mangled determination do not know how to correctly do it (for
example, they leave out Swift mangling prefixes).

This patch removes this entry point and just forced Mangled to
determine the mangledness of a string itself.

Differential Revision: https://reviews.llvm.org/D68674

llvm-svn: 374180

show more ...

Unify the two CRC implementations

David added the JamCRC implementation in r246590. More recently, Eugene
added a CRC-32 implementation in r357901, which falls back to zlib's
crc32 function if prese

Unify the two CRC implementations

David added the JamCRC implementation in r246590. More recently, Eugene
added a CRC-32 implementation in r357901, which falls back to zlib's
crc32 function if present.

These checksums are essentially the same, so having multiple
implementations seems unnecessary. This replaces the CRC-32
implementation with the simpler one from JamCRC, and implements the
JamCRC interface in terms of CRC-32 since this means it can use zlib's
implementation when available, saving a few bytes and potentially making
it faster.

JamCRC took an ArrayRef<char> argument, and CRC-32 took a StringRef.
This patch changes it to ArrayRef<uint8_t> which I think is the best
choice, and simplifies a few of the callers nicely.

Differential revision: https://reviews.llvm.org/D68570

llvm-svn: 374148

show more ...

Explicitly set entry point arch when it's thumb [Second Try]

Summary:
This is a redo of D68069 because I reverted it due to some concerns that were now addressed along with the new comments that @la

Explicitly set entry point arch when it's thumb [Second Try]

Summary:
This is a redo of D68069 because I reverted it due to some concerns that were now addressed along with the new comments that @labath added.

I found a case where the main android binary (app_process32) had thumb code at its entry point but no entry in the symbol table indicating this. This made lldb set a 4 byte breakpoint at that address (we default to arm code) instead of a 2 byte one (like we should for thumb).
The big deal with this is that the expression evaluator uses the entry point as a way to know when a JITed expression has finished executing by putting a breakpoint there. Because of this, evaluating expressions on certain android devices (Google Pixel something) made the process crash.
This was fixed by checking this specific situation when we parse the symbol table and add an artificial symbol for this 2 byte range and indicating that it's arm thumb.

I created 2 unit tests for this, one to check that now we know that the entry point is arm thumb, and the other to make sure we didn't change the behaviour for arm code.

I also run the following on the command line with the `app_process32` where I found the issue:
**Before:**
```
(lldb) dis -s 0x1640 -e 0x1644
app_process32[0x1640]: .long 0xf0004668 ; unknown opcode
```
**After:**
```
(lldb) dis -s 0x1640 -e 0x1644
app_process32`:
app_process32[0x1640] <+0>: mov r0, sp
app_process32[0x1642]: andeq r0, r0, r0
```

Reviewers: clayborg, labath, wallace, espindola

Reviewed By: labath

Subscribers: labath, lldb-commits, MaskRay, kristof.beyls, arichardson, emaste, srhines

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D68533

llvm-svn: 374132

show more ...

[lldb][ELF] Read symbols from .gnu_debugdata sect.

Summary:
If the .symtab section is stripped from the binary it might be that
there's a .gnu_debugdata section which contains a smaller .symtab in
o

[lldb][ELF] Read symbols from .gnu_debugdata sect.

Summary:
If the .symtab section is stripped from the binary it might be that
there's a .gnu_debugdata section which contains a smaller .symtab in
order to provide enough information to create a backtrace with function
names or to set and hit a breakpoint on a function name.

This change looks for a .gnu_debugdata section in the ELF object file.
The .gnu_debugdata section contains a xz-compressed ELF file with a
.symtab section inside. Symbols from that compressed .symtab section
are merged with the main object file's .dynsym symbols (if any).
In addition we always load the .dynsym even if there's a .symtab
section.

For example, the Fedora and RHEL operating systems strip their binaries
but keep a .gnu_debugdata section. While gdb already can read this
section, LLDB until this patch couldn't. To test this patch on a
Fedora or RHEL operating system, try to set a breakpoint on the "help"
symbol in the "zip" binary. Before this patch, only GDB can set this
breakpoint; now LLDB also can do so without installing extra debug
symbols:

lldb /usr/bin/zip -b -o "b help" -o "r" -o "bt" -- -h

The above line runs LLDB in batch mode and on the "/usr/bin/zip -h"
target:

(lldb) target create "/usr/bin/zip"
Current executable set to '/usr/bin/zip' (x86_64).
(lldb) settings set -- target.run-args "-h"

Before the program starts, we set a breakpoint on the "help" symbol:

(lldb) b help
Breakpoint 1: where = zip`help, address = 0x00000000004093b0

Once the program is run and has hit the breakpoint we ask for a
backtrace:

(lldb) r
Process 10073 stopped
* thread #1, name = 'zip', stop reason = breakpoint 1.1
frame #0: 0x00000000004093b0 zip`help
zip`help:
-> 0x4093b0 <+0>: pushq %r12
0x4093b2 <+2>: movq 0x2af5f(%rip), %rsi ; + 4056
0x4093b9 <+9>: movl $0x1, %edi
0x4093be <+14>: xorl %eax, %eax

Process 10073 launched: '/usr/bin/zip' (x86_64)
(lldb) bt
* thread #1, name = 'zip', stop reason = breakpoint 1.1
* frame #0: 0x00000000004093b0 zip`help
frame #1: 0x0000000000403970 zip`main + 3248
frame #2: 0x00007ffff7d8bf33 libc.so.6`__libc_start_main + 243
frame #3: 0x0000000000408cee zip`_start + 46

In order to support the .gnu_debugdata section, one has to have LZMA
development headers installed. The CMake section, that controls this
part looks for the LZMA headers and enables .gnu_debugdata support by
default if they are found; otherwise or if explicitly requested, the
minidebuginfo support is disabled.

GDB supports the "mini debuginfo" section .gnu_debugdata since v7.6
(2013).

Reviewers: espindola, labath, jankratochvil, alexshap

Reviewed By: labath

Subscribers: rnkovacs, wuzish, shafik, emaste, mgorny, arichardson, hiraditya, MaskRay, lldb-commits

Tags: #lldb, #llvm

Differential Revision: https://reviews.llvm.org/D66791

llvm-svn: 373891

show more ...

Revert "Explicitly set entry point arch when it's thumb"

Backing out because SymbolFile/Breakpad/symtab.test is failing and it seems to be a legit issue. Will investigate.

This reverts commit 72153

Revert "Explicitly set entry point arch when it's thumb"

Backing out because SymbolFile/Breakpad/symtab.test is failing and it seems to be a legit issue. Will investigate.

This reverts commit 72153f95ee4c1b52d2f4f483f0ea4f650ec863be.

llvm-svn: 373687

show more ...

Explicitly set entry point arch when it's thumb

Summary:
I found a case where the main android binary (app_process32) had thumb code at its entry point but no entry in the symbol table indicating th

Explicitly set entry point arch when it's thumb

Summary:
I found a case where the main android binary (app_process32) had thumb code at its entry point but no entry in the symbol table indicating this. This made lldb set a 4 byte breakpoint at that address (we default to arm code) instead of a 2 byte one (like we should for thumb).
The big deal with this is that the expression evaluator uses the entry point as a way to know when a JITed expression has finished executing by putting a breakpoint there. Because of this, evaluating expressions on certain android devices (Google Pixel something) made the process crash.
This was fixed by checking this specific situation when we parse the symbol table and add an artificial symbol for this 2 byte range and indicating that it's arm thumb.

I created 2 unit tests for this, one to check that now we know that the entry point is arm thumb, and the other to make sure we didn't change the behaviour for arm code.

I also run the following on the command line with the `app_process32` where I found the issue:
**Before:**
```
(lldb) dis -s 0x1640 -e 0x1644
app_process32[0x1640]: .long 0xf0004668 ; unknown opcode
```
**After:**
```
(lldb) dis -s 0x1640 -e 0x1644
app_process32`:
app_process32[0x1640] <+0>: mov r0, sp
app_process32[0x1642]: andeq r0, r0, r0
```

Reviewers: clayborg, labath, wallace, espindola

Subscribers: srhines, emaste, arichardson, kristof.beyls, MaskRay, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D68069

llvm-svn: 373680

show more ...

Revert "[LLDB][ELF] Load both, .symtab and .dynsym sections"

This reverts commit 3a4781bbf4f39a25562b4c61c9a9ab2483a96b41.

llvm-svn: 371625

Revert "[LLDB][ELF] Fixup for comments in D67390"

This reverts commit 813f05915d29904878d926f9849ca3dbe78096af.

llvm-svn: 371624