https://sourceware.org/bugzilla/show_bug.cgi?id=26822
Bug ID: 26822
Summary: How to prevent a STT_FILE with absolute path in the
linked image
Product: binutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
ld.bfd copies non-STT_SECTION local symbols from input object files.
If an object file does not have STT_FILE symbols (no .file directive) but has
non-STT_SECTION local symbols, ld.bfd synthesizes a STT_FILE symbol.
bfd/elflink.c
/* In the absence of debug info, bfd_find_nearest_line uses
FILE symbols to determine the source file for local
function symbols. Provide a FILE symbol here if input
files lack such, so that their symbols won't be
associated with a previous input file. It's not the
source file, but the best we can do. */
The ELF spec says:
> STT_FILE - Conventionally, the symbol's name gives the name of the source
> file associated with the object file. A file symbol has STB_LOCAL binding,
> its section index is SHN_ABS, and it precedes the other STB_LOCAL symbols for
> the file, if it is present.
Without the synthesized STT_FILE, consumers may attribute the copied STB_LOCAL
symbols to the previous file (with STT_FILE).
On ARM, mapping symbols (e.g. $a) can be everywhere.
For crti.o and crtn.o, compiler drivers pass the absolute paths to ld, so the
synthesized STT_FILE has an absolute path.
However, if the user wants to pursue "Local determinism: Like incremental basic
determinism, but builds are also independent of the name of the build
directory"
(https://blog.llvm.org/2019/11/deterministic-builds-with-clang-and-lld.html),
the absolute path can actually get in the way.
The usual -fdebug-prefix-map (-ffile-prefix-map) is not effective to the ld
synthesized paths.
--
You are receiving this mail because:
You are on the CC list for the bug.
