This patch improves the ability of a ObjectFileELF instance to read the
.dynamic section. It adds the ability to read the .dynamic section from
the PT_DYNAMIC program header which is useful for ELF files that have no
section headers and for ELF files that are read from memory. It cleans
up the usage of the .dynamic entries so that
ObjectFileELF::ParseDynamicSymbols() is the only code that parses
.dynamic entries, teaches that function the read and store the string
values for each .dynamic entry. We now dump the .dynamic entries in the
output of "image dump objfile". It also cleans up the code that gets the
dynamic string table so that it can grab it from the DT_STRTAB and
DT_STRSZ .dynamic entries for when we have a ELF file with no section
headers or we are reading it from memory.
This patch improves the ability of a ObjectFileELF instance to read the .dynamic section. It adds the ability to read the .dynamic section from the PT_DYNAMIC program header which is useful for ELF files that have no section headers and for ELF files that are read from memory. It cleans up the usage of the .dynamic entries so that ObjectFileELF::ParseDynamicSymbols() is the only code that parses .dynamic entries, teaches that function the read and store the string values for each .dynamic entry. We now dump the .dynamic entries in the output of "image dump objfile". It also cleans up the code that gets the dynamic string table so that it can grab it from the DT_STRTAB and DT_STRSZ .dynamic entries for when we have a ELF file with no section headers or we are reading it from memory.
PT_LOAD and PT_TLS segments are top level sections in the ObjectFileELF
section list. The two segments can often have the same program header
p_vaddr and p_paddr values and this can cause section load list issues
in LLDB if we load the PT_TLS segments. What happens is the
SectionLoadList::m_addr_to_sect, when a library is loaded, will first
map one of the sections named "PT_LOAD[0]" with the load address that
matches the p_vaddr entry from the program header. Then the "PT_TLS[0]"
would come along and try to load this section at the same address. This
would cause the "PT_LOAD[0]" section to be unloaded as the
SectionLoadList::m_addr_to_sect would replace the value for the matching
p_vaddr with the last section to be seen. The sizes of the PT_TLS and
PT_LOAD that have the same p_vaddr value don't need to have the same
byte size, so this could cause lookups to fail for an addresses in the
"PT_LOAD[0]" section or any of its children if the offset is greater
than the offset size of the PT_TLS segment. It could also cause us to
incorrectly attribute addresses from the "PT_LOAD[0]" to the "PT_TLS[0]"
segment when doing lookups for offset that are less than the size of the
PT_TLS segment.
This fix stops us from loading PT_TLS segments in the section load lists
and will prevent the bugs that resulted from this. No addresses the the
DWARF refer to TLS data with a "file address" in any way. They all have
TLS DWARF location expressions to locate these variables. We also don't
have any support for having actual thread specific sections and having
those sections resolve to something different for each thread, so there
currently is no point in loading thread specific sections. Both the
ObjectFileMachO and ObjectFileCOFF both ignore thread specific sections
at the moment, so this brings the ObjectFileELF to parity with those
plug-ins.
I added a test into an existing test to verify that things work as
expected.
Prior to this fix with a real binary, the output of "target dump
section-load-list" would look like this for the old LLDB:
```
// (lldb) target dump section-load-list
// addr = 0x0000000000000000, section = 0x55d46ab8c510: 0xfffffffffffffffd container [0x0000000000000000-0x0000000000000628) r-- 0x00000000 0x00000628 0x00000000 a.out.PT_LOAD[0]
// addr = 0x0000000000001000, section = 0x55d46ab8b0c0: 0xfffffffffffffffc container [0x0000000000001000-0x0000000000001185) r-x 0x00001000 0x00000185 0x00000000 a.out.PT_LOAD[1]
// addr = 0x0000000000002000, section = 0x55d46ac040f0: 0xfffffffffffffffb container [0x0000000000002000-0x00000000000020cc) r-- 0x00002000 0x000000cc 0x00000000 a.out.PT_LOAD[2]
// addr = 0x0000000000003db0, section = 0x55d46ab7cef0: 0xfffffffffffffff6 container [0x0000000000003db0-0x0000000000003db4) r-- 0x00002db0 0x00000000 0x00000000 a.out.PT_TLS[0]
```
And this for the fixed LLDB:
```
// (lldb) target dump section-load-list
// addr = 0x0000000000000000, section = 0x105f0a9a8: 0xfffffffffffffffd container [0x0000000000000000-0x0000000000000628) r-- 0x00000000 0x00000628 0x00000000 a.out.PT_LOAD[0]
// addr = 0x0000000000001000, section = 0x105f0adb8: 0xfffffffffffffffc container [0x0000000000001000-0x0000000000001185) r-x 0x00001000 0x00000185 0x00000000 a.out.PT_LOAD[1]
// addr = 0x0000000000002000, section = 0x105f0af48: 0xfffffffffffffffb container [0x0000000000002000-0x00000000000020cc) r-- 0x00002000 0x000000cc 0x00000000 a.out.PT_LOAD[2]
// addr = 0x0000000000003db0, section = 0x105f0b078: 0xfffffffffffffffa container [0x0000000000003db0-0x0000000000004028) rw- 0x00002db0 0x00000274 0x00000000 a.out.PT_LOAD[3]
```
We can see that previously the "PT_LOAD[3]" segment would be removed
from the section load list, and after the fix it remains and there is on
PT_TLS in the loaded sections.
Section unification cannot just use names, because it's valid for ELF
binaries to have multiple sections with the same name. We should check
other section properties too.
Fixes#88001.
rdar://124467787
Allow the ObjectFileELF plugin to resolve R_ARM_ABS32 relocations from AArch32 object files. This fixes https://github.com/llvm/llvm-project/issues/61948
The existing architectures work with RELA-type relocation records that read addend from the relocation entry. REL-type relocations in AArch32 store addend in-place.
The new function doesn't re-use ELFRelocation::RelocAddend32(), because the interface doesn't match: in addition to the relocation entry we need the actual target section memory.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D147642
According to `/usr/include/elf.h` and `lldb/source/Plugins/ObjectFile/ELF/ELFHeader.h`.
For ELF64 relocation, types of `offset` and `addend` should be `elf_addr` and `elf_sxword`.
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D145550
Currently ApplyReloctions() deals with different archs' relocation types
together (in a single `switch() {..}`). I think it is incorrect because
different relocation types of different archs may have same enum values.
For example:
`R_LARCH_32` and `R_X86_64_64` are both `1`;
`R_LARCH_64` and `R_X86_64_PC32` are both `2`.
This patch handles each arch in seperate `switch()` to solve the enum
values conflict issue.
And a new test is added for LoongArch64.
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D145462
I encountered an issue where `p &variable` was finding an incorrect address for
32-bit PIC ELF files loaded into a running process. The problem was that the
R_386_32 ELF relocations were not being applied to the DWARF section, so all
variables in that file were reporting as being at the start of their respective
section. There is an assert that catches this on debug builds, but silently
ignores the issue on non-debug builds.
In this changeset, I added handling for the R_386_32 relocation type to
ObjectFileELF, and a supporting function to ELFRelocation to differentiate
between DT_REL & DT_RELA in ObjectFileELF::ApplyRelocations().
Demonstration of issue:
```
[dmlary@host work]$ cat rel.c
volatile char padding[32] = "make sure var isnt at .data+0";
volatile char var[] = "test";
[dmlary@host work]$ gcc -c rel.c -FPIC -fpic -g -m32
[dmlary@host work]$ lldb ./exec
(lldb) target create "./exec"
Current executable set to '/home/dmlary/src/work/exec' (i386).
(lldb) process launch --stop-at-entry
Process 21278 stopped
* thread #1, name = 'exec', stop reason = signal SIGSTOP
frame #0: 0xf7fdb150 ld-2.17.so`_start
ld-2.17.so`_start:
-> 0xf7fdb150 <+0>: movl %esp, %eax
0xf7fdb152 <+2>: calll 0xf7fdb990 ; _dl_start
ld-2.17.so`_dl_start_user:
0xf7fdb157 <+0>: movl %eax, %edi
0xf7fdb159 <+2>: calll 0xf7fdb140
Process 21278 launched: '/home/dmlary/src/work/exec' (i386)
(lldb) image add ./rel.o
(lldb) image load --file rel.o .text 0x40000000 .data 0x50000000
section '.text' loaded at 0x40000000
section '.data' loaded at 0x50000000
(lldb) image dump symtab rel.o
Symtab, file = rel.o, num_symbols = 13:
Debug symbol
|Synthetic symbol
||Externally Visible
|||
Index UserID DSX Type File Address/Value Load Address Size Flags Name
------- ------ --- --------------- ------------------ ------------------ ------------------ ---------- ----------------------------------
[ 0] 1 SourceFile 0x0000000000000000 0x0000000000000000 0x00000004 rel.c
[ 1] 2 Invalid 0x0000000000000000 0x0000000000000020 0x00000003
[ 2] 3 Invalid 0x0000000000000000 0x50000000 0x0000000000000020 0x00000003
[ 3] 4 Invalid 0x0000000000000025 0x0000000000000000 0x00000003
[ 4] 5 Invalid 0x0000000000000000 0x0000000000000020 0x00000003
[ 5] 6 Invalid 0x0000000000000000 0x0000000000000020 0x00000003
[ 6] 7 Invalid 0x0000000000000000 0x0000000000000020 0x00000003
[ 7] 8 Invalid 0x0000000000000000 0x0000000000000020 0x00000003
[ 8] 9 Invalid 0x0000000000000000 0x0000000000000020 0x00000003
[ 9] 10 Invalid 0x0000000000000000 0x0000000000000020 0x00000003
[ 10] 11 Invalid 0x0000000000000000 0x0000000000000020 0x00000003
[ 11] 12 X Data 0x0000000000000000 0x50000000 0x0000000000000020 0x00000011 padding
[ 12] 13 X Data 0x0000000000000020 0x50000020 0x0000000000000005 0x00000011 var
(lldb) p &var
(volatile char (*)[5]) $1 = 0x50000000
```
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D132954
clang 14 removed -gz=zlib-gnu support and ld.lld/llvm-objcopy removed zlib-gnu
support recently. Remove lldb support by migrating away from
llvm::object::Decompressor::isCompressedELFSection.
The API has another user llvm-dwp, so it is not removed in this patch.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D129724
(With C++ exceptions, `clang++ --target=mips64{,el}-linux-gnu -fpie -pie
-fuse-ld=lld` has link errors (lld does not implement some strange R_MIPS_64
.eh_frame handling in GNU ld). However, sanitizer-x86_64-linux-qemu used this to
build ScudoUnitTests. Pined ScudoUnitTests to -no-pie.)
Default the option introduced in D113372 to ON to match all(?) major Linux
distros. This matches GCC and improves consistency with Android and linux-musl
which always default to PIE.
Note: CLANG_DEFAULT_PIE_ON_LINUX may be removed in the future.
Differential Revision: https://reviews.llvm.org/D120305
(The upgrade of the ppc64le bot and D121257 have fixed compiler-rt failures. Tested by nemanjai.)
Default the option introduced in D113372 to ON to match all(?) major Linux
distros. This matches GCC and improves consistency with Android and linux-musl
which always default to PIE.
Note: CLANG_DEFAULT_PIE_ON_LINUX may be removed in the future.
Differential Revision: https://reviews.llvm.org/D120305
See post-commit discussion on https://reviews.llvm.org/D120305.
This change breaks the clang-ppc64le-rhel buildbot, though
there is suspicion that it's an issue with the bot. The change
also had a larger than expected impact on compile-time and
code-size.
This reverts commit 3c4ed02698afec021c6bca80740d1e58e3ee019e
and some followup changes.
This patch removes XFAIL from minidebuginfo-set-and-hit-breakpoint.test.
Test started passing after 3c4ed02698afec021c6bca80740d1e58e3ee019e.
Differential Revision: https://reviews.llvm.org/D120305
minidebuginfo-set-and-hit-breakpoint.test is failing on Arm/Linux most
probably due to an ill formed binary after removal of certain sections
from executable. I am marking it as XFAIL for further investigation.
Only lldb-arm-ubuntu is failing after https://reviews.llvm.org/D114288 and there isn't enough input context to see why this is failing. It works on x86_64 linux just fine.
LLDB build were failing due to following two test failures:
lldb-shell :: ObjectFile/ELF/basic-info.yaml
lldb-shell :: SymbolFile/DWARF/x86/debug-types-address-ranges.s
There were caused by commit 6506907a0a1a8a789ad7036ef911f7e31213c9a5
This is a resubmission of https://reviews.llvm.org/D105160 after fixing testing issues.
This fix was created after profiling the target creation of a large C/C++/ObjC application that contained almost 4,000,000 redacted symbol names. The symbol table parsing code was creating names for each of these synthetic symbols and adding them to the name indexes. The code was also adding the object file basename to the end of the symbol name which doesn't allow symbols from different shared libraries to share the names in the constant string pool.
Prior to this fix this was creating 180MB of "___lldb_unnamed_symbol" symbol names and was taking a long time to generate each name, add them to the string pool and then add each of these names to the name index.
This patch fixes the issue by:
not adding a name to synthetic symbols at creation time, and allows name to be dynamically generated when accessed
doesn't add synthetic symbol names to the name indexes, but catches this special case as name lookup time. Users won't typically set breakpoints or lookup these synthetic names, but support was added to do the lookup in case it does happen
removes the object file baseanme from the generated names to allow the names to be shared in the constant string pool
Prior to this fix the startup times for a large application was:
12.5 seconds (cold file caches)
8.5 seconds (warm file caches)
After this fix:
9.7 seconds (cold file caches)
5.7 seconds (warm file caches)
The names of the symbols are auto generated by appending the symbol's UserID to the end of the "___lldb_unnamed_symbol" string and is only done when the name is requested from a synthetic symbol if it has no name.
Differential Revision: https://reviews.llvm.org/D106837
This reverts commit c8164d0276b97679e80db01adc860271ab4a5d11 and
43f6dad2344247976d5777f56a1fc29e39c6c717 because it breaks
TestDyldTrieSymbols.py on GreenDragon.
This fix was created after profiling the target creation of a large C/C++/ObjC application that contained almost 4,000,000 redacted symbol names. The symbol table parsing code was creating names for each of these synthetic symbols and adding them to the name indexes. The code was also adding the object file basename to the end of the symbol name which doesn't allow symbols from different shared libraries to share the names in the constant string pool.
Prior to this fix this was creating 180MB of "___lldb_unnamed_symbol" symbol names and was taking a long time to generate each name, add them to the string pool and then add each of these names to the name index.
This patch fixes the issue by:
- not adding a name to synthetic symbols at creation time, and allows name to be dynamically generated when accessed
- doesn't add synthetic symbol names to the name indexes, but catches this special case as name lookup time. Users won't typically set breakpoints or lookup these synthetic names, but support was added to do the lookup in case it does happen
- removes the object file baseanme from the generated names to allow the names to be shared in the constant string pool
Prior to this fix the startup times for a large application was:
12.5 seconds (cold file caches)
8.5 seconds (warm file caches)
After this fix:
9.7 seconds (cold file caches)
5.7 seconds (warm file caches)
The names of the symbols are auto generated by appending the symbol's UserID to the end of the "___lldb_unnamed_symbol" string and is only done when the name is requested from a synthetic symbol if it has no name.
Differential Revision: https://reviews.llvm.org/D105160
Reverts commits:
"Fix failing tests after https://reviews.llvm.org/D104488."
"Fix buildbot failure after https://reviews.llvm.org/D104488."
"Create synthetic symbol names on demand to improve memory consumption and startup times."
This series of commits broke the windows lldb bot and then failed to fix all of the failing tests.
The code used the total number of symbols to create a symbol ID for the
synthetic symbols. This is not correct because the IDs of real symbols
can be higher than their total number, as we do not add all symbols (and
in particular, we never add symbol zero, which is not a real symbol).
This meant we could have symbols with duplicate IDs, which caused
problems if some relocations were referring to the duplicated IDs. This
was the cause of the failure of the test D97786.
This patch fixes the code to use the ID of the highest (last) symbol
instead.
It is possible for the GetSectionHeaderByIndex lookup to fail because
the previous FindSectionContainingFileAddress lookup found a segment
instead of a section. This is possible if the binary does not have
a PLT (which means that lld will in some circumstances set DT_JMPREL
to 0, which is typically an address that is part of the ELF headers
and not in a section) and may also be possible if the section headers
have been stripped. To handle this possibility, replace the assert
with an if.
Differential Revision: https://reviews.llvm.org/D93438
D95354 started to set the sh_link field for SHT_SYMTAB sections.
Previously it was set for symbol tables basing on their names (e.g. ".symtab").
This test now crashes see:
http://lab.llvm.org:8011/#/builders/68/builds/5911
I updated it to restore the old behavior.
Adds the RISC-V ArchSpec bits contributed by @simoncook as part of D62732,
plus logic to distinguish between riscv32 and riscv64 based on ELF class.
The patch follows the implementation approach previously used for MIPS.
It defines RISC-V architecture subtypes and inspects the ELF header,
namely the ELF class, to detect the right subtype.
Differential Revision: https://reviews.llvm.org/D86292
This patch fixes minidebuginfo-set-and-hit-breakpoint.test for arm-linux
targets. 32-bit elf executables use .rel.dyn and 64-bit uses .rela.dyn for
relocation entries for dynamic symbols.
This commit adds AVR support to lldb. With this change, it can load a
binary and do basic things like dump a line table.
Not much else has been implemented, that should be done in later
changes.
Differential Revision: https://reviews.llvm.org/D73539
%lldb is the proper substitution. Using "lldb" can cause us to execute
the system lldb instead of the one we are testing. This happens at least
in standalone builds.
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.
Summary:
This patch addresses an ambiguity in how our existing tests invoke the
compiler. Roughly two thirds of our current "shell" tests invoke the
compiler to build the executables for the host. However, there is also
a significant number of tests which don't build a host binary (because
they don't need to run it) and instead they hardcode a certain target.
We also have code which adds a bunch of default arguments to the %clang
substitutions. However, most of these arguments only really make sense
for the host compilation. So far, this has worked mostly ok, because the
arguments we were adding were not conflicting with the target-hardcoding
tests (though they did provoke an occasional "argument unused" warning).
However, this started to break down when we wanted to use
target-hardcoding clang-cl tests (D69031) because clang-cl has a
substantially different command line, and it was getting very confused
by some of the arguments we were adding on non-windows hosts.
This patch avoid this problem by creating separate %clang(xx,_cl)_host
substutitions, which are specifically meant to be used for compiling
host binaries. All funny host-specific options are moved there. To
ensure that the regular %clang substitutions are not used for compiling
host binaries (skipping the extra arguments) I employ a little
hac^H^H^Htrick -- I add an invalid --target argument to the %clang
substitution, which means that one has to use an explicit --target in
order for the compilation to succeed.
Reviewers: JDevlieghere, aprantl, mstorsjo, espindola
Subscribers: emaste, arichardson, MaskRay, jfb, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69619
Summary:
After D69041, we no longer have to manually remove the .symtab section
once yaml2obj was run.
Reviewers: espindola, alexshap
Subscribers: emaste, arichardson, MaskRay, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69254
llvm-svn: 375415
This was failing for me because of this error:
llvm-objcopy: error: 'build/tools/lldb/test/ObjectFile/ELF/Output/minidebuginfo-set-and-hit-breakpoint.test.tmp.mini_debuginfo': section '.dynsym' cannot be removed because it is referenced by the section '.hash'
Patch by Konrad Kleine!
llvm-svn: 374352
LLDB has three major testing strategies: unit tests, tests that exercise
the SB API though dotest.py and what we currently call lit tests. The
later is rather confusing as we're now using lit as the driver for all
three types of tests. As most of this grew organically, the directory
structure in the LLDB repository doesn't really make this clear.
The 'lit' tests are part of the root and among these tests there's a
Unit and Suite folder for the unit and dotest-tests. This layout makes
it impossible to run just the lit tests.
This patch changes the directory layout to match the 3 testing
strategies, each with their own directory and their own configuration
file. This means there are now 3 directories under lit with 3
corresponding targets:
- API (check-lldb-api): Test exercising the SB API.
- Shell (check-lldb-shell): Test exercising command line utilities.
- Unit (check-lldb-unit): Unit tests.
Finally, there's still the `check-lldb` target that runs all three test
suites.
Finally, this also renames the lit folder to `test` to match the LLVM
repository layout.
Differential revision: https://reviews.llvm.org/D68606
llvm-svn: 374184
