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

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/6eba854f/attachment.html>

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>

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/20180206/bbf4fef1/attachment.html>

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>