https://sourceware.org/bugzilla/show_bug.cgi?id=32506
nyanpasu64 at tuta dot io changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |nyanpasu64 at tuta dot io
--- Comment #5 from nyanpasu64 at tuta dot io ---
I've been encountering a similar issue at Bug 34464. Tom Tromey linked to Bug
34389, where someone proposed a gdb patch to (I think) ignore DWARF symbols at
0 and fall back to the unaffected symbol table, though Tom Tromey rejected the
patch and suggested implementing it in the DWARF reader rather than symbol
resolver. I have not written any source patches for that, and AFAIK Tom has not
attempted that either.
## binutils ld patch?
According to https://dwarfstd.org/issues/200609.1.html, DWARF v6 has
standardized address -1 (0xffffffff, the same address suggested by Richard
Biener here) as a placeholder for functions removed, eg. by GC or code folding.
I think it would be ideal for ld to do this for current DWARF versions as well,
to fix similar issues in the present.
(This does carry the risk of integer overflow, though lld already does it since
D82899 was committed in 2020, so DWARF-processing tools should have already
adapted by now. There's some discussion in https://reviews.llvm.org/D59553
about address -2 in range sections, though it seemed to have been abandoned in
the merged change, though gdb/dwarf2/read.c
#lnp_state_machine::check_line_address still checks for -2, -1, *and* 0.)
If you don't want to change DW_AT_low_pc to -1 for DWARF≤5, you can instead set
DW_AT_high_pc to 0, effectively turning GCed functions into zero-length which
should not overlap with real code. I implemented this change in my ELF patcher
at https://codeberg.org/nyanpasu64/patch-dwarf/src/branch/dev/patchdwarf.py.
This hasn't caused problems in my testing, and shouldn't have any negative
consequences I can think of (unless a consumer assumes all subprograms have at
least 1 byte or instruction).
### Sidenote: What causes the gdb issue?
In Bug 34464 Tom also commented:
> I suspect the reason is that this ELF has a section at zero:
>
> $ readelf -WS sys-ftpd.elf
> ...
> [ 1] .text PROGBITS 0000000000000000 010000 032af0 00
> AX 0 0 64
>
>
> This means that a symbol with PC=0 might be valid, so gdb's DWARF reader
> skips the GC function stuff in this case...
Why would ELFs have sections at zero? https://reviews.llvm.org/D59553 suggests
"linker script"s are the cause, hence why *four* independent people have run
into the same issue on embedded or memory-constrained platforms (where GCed
sections and linker scripts are common, though I'm not sure why they're using
PIE).
--
You are receiving this mail because:
You are on the CC list for the bug.
