[llvm-dev] [RFC] Add mergeable and eh_frame section pieces to map files and --print-gc/icf-sections reports

[James Henderson via llvm-dev]

I've uploaded an example patch to demo .eh_frame support in the map file:

https://reviews.llvm.org/D42960

On 6 February 2018 at 12:27, James Henderson <jh7370.2008 at my.bristol.ac.uk>
wrote:

> Hi,
>
>
>
> We’d like to propose an extension to both the map file and the
> print-gc/icf-sections output. This extension would be to report the pieces
> of .eh_frame and SHF_MERGE sections in these files somehow. Since all (or
> at least the majority) of the contents of these sections in the output come
> from inputs, it would be beneficial in trying to associate the output
> contents with where they came from, helping with debugging and analysis as
> required. Our proposal is to give these pieces special names, which
> indicate their offset and input section. An example in --print-gc-sections
> output might be something like:
>
> > ld.lld test.o -o test.elf --gc-sections --print-gc-sections
>
> “removing section piece ‘.eh_frame+0x1234’ from file ‘test.o’”
>
> “removing section piece ‘.rodata.str1.1+0x1234’ from file ‘test.o’”
>
> A map file reference would look the same as for other input sections, but
> again with a reference to the offset within the section.
>
>
>
> At the moment, such pieces are not mentioned in the print-gc-sections
> output, and appear as “internal” in the map file, which is clearly not
> entirely accurate, since they came from one of the inputs.
>
>
>
> For reference, in the map file, ld.bfd reports the original size of
> .eh_frame sections before any relaxing/GC-ing etc, even if the section is
> empty:
>
> .eh_frame      0x0000000000400130       0x20 eh2.o
>
>                                          0x38 (size before relaxing)
>
> Gold meanwhile does something similar to LLD, which is to say that the
> section is generated by the linker. Neither mention the .eh_frame section
> in the --print-gc -sections report. For mergeable sections, the behaviour
> is similar for both.
>
>
>
> Before going ahead with uploading a patch for review for this, we would
> like some feedback on this proposal.
>
>
>
> Regards,
>
>
> James
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180206/c6c7897c/attachment.html>