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

[James Henderson via llvm-dev]

The use-case would be the same as for any other entry in the map file: to
provide a way for a user to determine the mapping between the inputs and
the output of the linker, without needing to cross-reference the section
contents. I've often found the map file a good way of trying to analyse
what's happening with section layout, usually for debugging purposes, but
sometimes also as a first-pass when testing and experimenting (although I
acknowledge that we shouldn't rely solely on the map file for testing).

On 6 February 2018 at 22:43, Rui Ueyama <ruiu at google.com> wrote:

> It seems that showing eh_frame section pieces in the map file is useful,
> but I wonder what would be a concrete use case of the feature. Do you mind
> if you ask you to describe your plan if you have a use case in mind?
>
> On Tue, Feb 6, 2018 at 4:27 AM, 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/20180207/9e26fa88/attachment.html>