[llvm-dev] [RFC] Add mergeable and eh_frame section pieces to map files and --print-gc/icf-sections reports
James Henderson via llvm-dev
llvm-dev at lists.llvm.org
Tue Feb 6 04:27:10 PST 2018
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
.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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev