Range lists, zero-length functions, linker gc

Fangrui Song maskray@google.com
Wed Jun 3 04:06:29 GMT 2020


On 2020-06-03, Alan Modra 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 <mark@klomp.org> 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.
>
>-- 
>Alan Modra
>Australia Development Lab, IBM

sizeof(Elf64_Shdr) = 64.

If we create a .debug_line fragment and a .debug_info fragment for a
function, we waste 128 bytes.

https://sourceware.org/pipermail/binutils/2020-May/111361.html

> .debug_line.bar

We should use the unique linkage feature https://sourceware.org/bugzilla/show_bug.cgi?id=25380
otherwise we also waste lots of bytes for the .debug_*.* section names.


More information about the Gdb mailing list