[Bug symtab/34464] GCC binaries in -fPIE -ffunction-sections --gc-sections have DWARF subprograms overlapping main, breaking function resolution

https://sourceware.org/bugzilla/show_bug.cgi?id=3D34464

--- Comment #3 from nyanpasu64 at tuta dot io ---
Hmm I tried filing an issue for the ld bug, but the "possible duplicates"
turned up a more-or-less similar issue in Bug 32506, which references both =
Bug
13415 and GCC's https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D118221 (by t=
he
same author as 32506). 32506 already references possibly putting GCed secti=
ons
at 0xffffffff. It (mostly) doesn't mention DWARF by name, but the symptoms =
seem
to match (though they used objdump as well as gdb).

I did test objdump on the x86 and ARM64 binaries, though didn't get the
*hundreds* of name aliases on a single null address that appeared in dwex a=
nd
Ghidra, so I don't know where objdump gets its function names from. Funnily
enough, objdump *does* show unused0 on my x86 binary, but gdb doesn't resol=
ve
it to a symbol.

Bug 13415 references a gdb comment saying that gdb/dwarf2/read.c
#lnp_state_machine::check_line_address already checks for GC'd functions at=
 0,
-1, or -2. Apparently this check isn't working here? In any case I think it=
's a
good place for me to start debugging *why* gdb properly filters out functio=
ns
at 0 on x86 but not ARM64 (or 32506's Cortex-M0 embedded project).

Bug 13415 also links to
https://github.com/llvm/llvm-project/commit/e618ccbf431f6730edb6d1467a127c3=
a52fd57f7,
which links to https://dwarfstd.org/issues/200609.1.html as I referenced.

Would it suffice to comment on Bug 32506 that the DWARF standard has specif=
ied
in (unreleased) version 6 that GCed functions should have their low PC set =
to
-1/0x...FFFF, and it may be worth changing ld to avoid ambiguity which has =
led
to three independent bug reports so far? (We *would* have to test for
regressions in tooling still, as arithmetic on 0x...FFFF is highly prone to
integer overflow if not checked. But lld binaries already have this behavio=
r,
so tools *should* handle it already?)

--=20
You are receiving this mail because:
You are on the CC list for the bug.=