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

On Tue, Jun 2, 2020 at 8:10 PM Alan Modra <[email protected]> wrote:
>
> On Tue, Jun 02, 2020 at 11:06:10AM -0700, David Blaikie via Binutils wrote:
> > On Tue, Jun 2, 2020 at 9:50 AM Mark Wielaard <[email protected]> wrote:
> > > where I
> > > would argue the compiler simply needs to make sure that if it generates
> > > code in separate sections it also should create the DWARF separate
> > > section (groups).
> >
> > I don't think that's practical - the overhead, I believe, is too high.
> > Headers for each section contribution (ELF headers but DWARF headers
> > moreso - having a separate .debug_addr, .debug_line, etc section for
> > each function would be very expensive) would make for very large
> > object files.
>
> With a little linker magic I don't see the neccesity of duplicating
> the DWARF headers.  Taking .debug_line as an example, a compiler could
> emit the header, opcode, directory and file tables to a .debug_line
> section with line statements for function foo emitted to
> .debug_line.foo and for bar to .debug_line.bar, trusting that the
> linker will combine these sections in order to create an output
> .debug_line section.  If foo code is excluded then .debug_line.foo
> info will also be dropped if section groups are used.

I don't think this would apply to debug_addr - where the entries are
referenced from elsewhere via index, or debug_rnglist where the
rnglist header (or the debug_info directly) contains offsets into this
section, so taking chunks out would break those offsets. (or to the
file/directory name part of debug_line - where you might want to
remove file/line entries that were eliminated as dead code - but
that'd throw off the indexes)