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

[Mark Wielaard <mark@klomp.org>]

Hi,

On Sun, May 31, 2020 at 01:47:38PM -0700, Fangrui Song via Elfutils-devel wrote:
> On 2020-05-31, Mark Wielaard wrote:
> > 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.
> 
> I would love if we could solve the problem using ELF features, but
> putting DW_TAG_subprogram in the same section group is not an
> unqualified win

Sorry for pushing back a little, but as a DWARF consumer this feels a
little like the DWARF producer hasn't tried hard enough to produce
valid DWARF and now tries to pass the problems off onto the DWARF
consumer. Or when looking at it from the perspective of the linker,
the compiler gave it an impossible problem to solve because it didn't
really get all the pieces of the puzzle (the compiler already fused
some independent parts together).

I certainly appreciate the issue on 32-bit systems. It seems we
already have reached the limits for some programs to be linked (or
produce all the debuginfo) when all you got is 32-bits.

But maybe that means that the problem is actually that the compiler
already produced too much code/data. And the issue really is that it
passes some problems, like unused code elimination, off to the
linker. While the compiler really should have a better view of that,
and should do that job itself. If it did, then it would never even
produce the debuginfo in the first place.

GCC used to produce horrible DWARF years ago with early LTO
implementations, because they just handed it all off to the linker to
figure out. But they solved it by generating DWARF in phases, only
when it was known the DWARF was valid/consistent did it get
produced. So that if some code was actually eliminated then the linker
never even see any "code ranges" for code that disappeared. See Early
Debug: https://gcc.gnu.org/wiki/early-debug

Might some similar technique, where the compiler does a bit more work,
so that it actually produces less DWARF to be processed by the linker,
be used here?

Sorry for pushing the problem back to the producer side, but as a
consumer I think that is the more correct place to solve this.

Cheers,

Mark