Re: Range lists, zero-length functions, linker gc

On Sun, May 31, 2020 at 1:41 PM Mark Wielaard <[email protected]> wrote:
>
> Hi,
>
> On Sun, May 31, 2020 at 11:55:06AM -0700, Fangrui Song via Elfutils-devel wrote:
> > what linkers should do regarding relocations referencing dropped
> > functions (due to section group rules, --gc-sections, /DISCARD/,
> > etc) in .debug_*
> >
> > As an example:
> >
> >   __attribute__((section(".text.x"))) void f1() { }
> >   __attribute__((section(".text.x"))) void f2() { }
> >   int main() { }
> >
> > Some .debug_* sections are relocated by R_X86_64_64 referencing
> > undefined symbols (the STT_SECTION symbols are collected):
> >
> >   0x00000043:   DW_TAG_subprogram [2]
> >                   ###### relocated by .text.x + 10
> >                   DW_AT_low_pc [DW_FORM_addr]     (0x0000000000000010 ".text.x")
> >                   DW_AT_high_pc [DW_FORM_data4]   (0x00000006)
> >                   DW_AT_frame_base [DW_FORM_exprloc]      (DW_OP_reg6 RBP)
> >                   DW_AT_linkage_name [DW_FORM_strp]       ( .debug_str[0x0000002c] = "_Z2f2v")
> >                   DW_AT_name [DW_FORM_strp]       ( .debug_str[0x00000033] = "f2")
> >
> >
> > With ld --gc-sections:
> >
> > * DW_AT_low_pc [DW_FORM_addr] in .debug_info are resolved to 0 +
> >   addend This can cause overlapping address ranges with normal text
> >   sections. {{overlap}} * [beginning address offset, ending address
> >   offset) in .debug_ranges are resolved to 1 (ignoring addend).  See
> >   bfd/reloc.c (behavior introduced in
> >   https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=e4067dbb2a3368dbf908b39c5435c84d51abc9f3
> >   )
> >
> >   [0, 0) cannot be used because it terminates the list entry.
> >   [-1, -1) cannot be used because -1 represents a base address
> >   selection entry which will affect subsequent address offset
> >   pairs.
> > * .debug_loc address offset pairs have similar problem to .debug_ranges
> > * In DWARF v5, the abnormal values can be in a separate section .debug_addr
> >
> > ---
> >
> > I am eager to know what you think
> > of the ideas from binutils/gdb/elfutils's perspective.
>
> I think this is a producer problem. If a (code) section can be totally
> dropped then the associated (.debug) sections should have been
> generated together with that (code) section in a COMDAT group. That
> way when the linker drops that section, all the associated sections in
> that COMDAT group will get dropped with it. If you don't do that, then
> the DWARF is malformed and there is not much a consumer can do about
> it.
>
> Said otherwise, I don't think it is correct for the linker (with
> --gc-sections) to drop any sections that have references to it
> (through relocation symbols) from other (.debug) sections.

That's probably not practical for at least some users - the
easiest/most thorough counter-example is Split DWARF - the DWARF is in
another file the linker can't see. All the linker sees is a list of
addresses (debug_addr).

All 3 linkers have (modulo bugs) supported this situation, to varying
degrees, for decades (ld.bfd: resolve to zero everywhere, resolve to 1
in debug_ranges, lld/gold: resolve to 0+addend) & this is an attempt
to fix the bugs & maybe make the solution a bit more robust/work for
more cases/be more intentional.

(even if not for Split DWARF - creating DWARF that can be dropped by a
non-DWARF-aware linker (ie: one that doesn't have to parse/rebuild all
the DWARF at link time - which would be super expensive (though
someone's prototyping that in lld for those willing to pay that
tradeoff)) involves larger DWARF which isn't always a great tradeoff -
some users care a lot more about object size than executable size (and
maybe increased link time - due to more sections, etc))