[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

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

https://reviews.llvm.org/D42960

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?

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).