mirror of
https://github.com/capstone-engine/llvm-capstone.git
synced 2025-02-13 22:00:14 +00:00
e618ccbf43
See D59553, https://lists.llvm.org/pipermail/llvm-dev/2020-May/141885.html and https://sourceware.org/pipermail/binutils/2020-May/111357.html for extensive discussions on a tombstone value. See http://www.dwarfstd.org/ShowIssue.php?issue=200609.1 (Reserve an address value for "not present") for a DWARF enhancement proposal. We resolve such relocations to a tombstone value to indicate that the address is invalid. This solves several problems (the normal behavior is to resolve the relocation to the addend): * For an empty function in a collected section, a pair of (0,0) can terminate .debug_loc and .debug_ranges (as of binutils 2.34, GNU ld resolves such a relocation to 1 to avoid the .debug_ranges issue) * If DW_AT_high_pc is sufficiently large, the address range can collide with a regular code range of low address (https://bugs.llvm.org/show_bug.cgi?id=41124 ) * If a text section is folded into another by ICF, we may leave entries in multiple CUs claiming ownership of the same range of code, which can confuse consumers. * Debug information associated with COMDAT sections can have problems similar to ICF, but is more complex - thus not addressed by this patch. For pre-DWARF-v5 .debug_loc and .debug_ranges, a pair of 0 can terminate entries (invalidating subsequent ranges). -1 is a reserved value with special meaning (base address selection entry) which can't be used either. Use -2 instead. For all other .debug_*, use UINT32_MAX for 32-bit targets and UINT64_MAX for 64-bit targets. In the code, we intentionally use `uint64_t tombstone = UINT64_MAX` for 32-bit targets as well: this matches SignExtend64 as used in `relocateAlloc`. (Actually UINT32_MAX does not work for R_386_32) Note 0, we only special case `target->symbolicRel` (R_X86_64_64, R_AARCH64_ABS64, R_PPC64_ADDR64), not short-range absolute relocations (e.g. R_X86_64_32). Only forms like DW_FORM_addr need to be special cased. They can hold an arbitrary address (must be 64-bit on a 64-bit target). (In theory, producers can make use of small code model to emit 32-bit relocations. This doesn't seem to be leveraged.) Note 1, we have to ignore the addend, because we don't want to resolve DW_AT_low_pc (which may have a non-zero addend) to -1+addend (wrap around to a low address): __attribute__((section(".text.x"))) void f1() { } __attribute__((section(".text.x"))) void f2() { } // DW_AT_low_pc has a non-zero addend Note 2, if the prevailing copy does not have debugging information while a non-prevailing copy has (partial debug build), we don't do extra work to attach debugging information to the prevailing definition. (clang has a lot of debug info optimizations that are on-by-default that assume the whole program is built with debug info). clang -c -ffunction-sections a.cc # prevailing copy has no debug info clang -c -ffunction-sections -g b.cc Reviewed By: dblaikie, avl, jhenderson Differential Revision: https://reviews.llvm.org/D81784
LLVM Linker (lld)
This directory and its subdirectories contain source code for the LLVM Linker, a modular cross platform linker which is built as part of the LLVM compiler infrastructure project.
lld is open source software. You may freely distribute it under the terms of the license agreement found in LICENSE.txt.
Benchmarking
In order to make sure various developers can evaluate patches over the same tests, we create a collection of self contained programs.
It is hosted at https://s3-us-west-2.amazonaws.com/linker-tests/lld-speed-test.tar.xz
The current sha256 is 10eec685463d5a8bbf08d77f4ca96282161d396c65bd97dc99dbde644a31610f.