<div dir="ltr">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?</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 6, 2018 at 4:27 AM, James Henderson <span dir="ltr"><<a href="mailto:jh7370.2008@my.bristol.ac.uk" target="_blank">jh7370.2008@my.bristol.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">

<p class="MsoNormal">Hi,</p>

<p class="MsoNormal"> </p>

<p class="MsoNormal">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:</p>

<p class="MsoNormal"><span style="font-family:"Courier New"">> ld.lld test.o
-o test.elf --gc-sections --print-gc-sections</span></p>

<p class="MsoNormal"><span style="font-family:"Courier New"">“removing section
piece ‘.eh_frame+0x1234’ from file ‘test.o’” </span></p>

<p class="MsoNormal"><span style="font-family:"Courier New"">“removing section
piece ‘.rodata.str1.1+0x1234’ from file ‘test.o’”</span></p>

<p class="MsoNormal">A map file reference would look the same as for other input
sections, but again with a reference to the offset within the section.</p>

<p class="MsoNormal"> </p>

<p class="MsoNormal">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.</p>

<p class="MsoNormal"> </p>

<p class="MsoNormal">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:</p>

<p class="MsoNormal"><span style="font-family:"Courier New"">.eh_frame     
0x0000000000400130       0x20 eh2.o</span></p>

<p class="MsoNormal"><span style="font-family:"Courier New""> 
                              <wbr>         0x38
(size before relaxing)</span></p>

<p class="MsoNormal">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. </p>

<p class="MsoNormal"> </p>

<p class="MsoNormal">Before going ahead with uploading a patch for review for
this, we would like some feedback on this proposal.</p>

<p class="MsoNormal"> </p>

<p class="MsoNormal">Regards,</p><span class="HOEnZb"><font color="#888888">

<p class="MsoNormal"> </p>

<span style="font-size:11pt;font-family:"Calibri",sans-serif">James</span></font></span></div>
</blockquote></div><br></div>