It is inspired by comments for PR35248 though not directly relative to it.
It turns out we do not show the internal layout for mergeable sections when
producing Map file. Though it can be useful to show where is content coming from and
what is initial size (before mrging) and final size.
Patch adds support for dumping such sections.
Details
Diff Detail
Event Timeline
How is this useful? Also, this change creates a malformed output that breaks the assumption that the 6th column contains symbol names.
Isn't one of intentions of map file to show where are sections coming from ? Currently we don't print
file names for SHF_MERGE sections, that looks inconsistent with how we dump regular sections.
Also I think it can be useful to show difference between input and output size. That can be applied for mergeable
sections and also for compressed input/output ones.
Also, this change creates a malformed output that breaks the assumption that the 6th column contains symbol names.
Oops, I missed header says its should be symbol, sorry.
Will it make sence to omit synthetic part (which is there only because of our internal representation and not useful)
and print something like following then ?
Address Size Align Out In 0000000000000000 0000000000000008 2 .strings 0000000000000000 0000000000000004 1 {{.*}}{{/|\\}}map-file.s.tmp1.o:(.strings) 0000000000000000 0000000000000008 2 {{.*}}{{/|\\}}map-file.s.tmp2.o:(.strings)
First of all, the current output is consistent. It doesn't print out the information about mergeable input sections that consist make up an mergeable synthetic section, but that doesn't mean that the output is inconsistent.
So, back to the original question, I don't think the format you are proposing is useful for a few reasons:
- Address and size fields contains bogus values. So you cannot use these numbers to analyze the output
- There's no good way of printing out input sections that make up a synthetic section in the current format
I think the fundamental issue of this patch is that the information you are trying to print out doesn't actually fit well in the notion of the map file. The map file is to show how input sections are mapped to some contiguous output memory address, and it's not suitable to print out the information as to how mergeable section pieces are mapped to an output section.
I cant just agree here, because they contain exactly what I wanted to see, but I should admit I might have misunderstood the
intention of map file. So it can be true. Let me think about it. Thank you for explanation.
- There's no good way of printing out input sections that make up a synthetic section in the current format
I think the fundamental issue of this patch is that the information you are trying to print out doesn't actually fit well in the notion of the map file. The map file is to show how input sections are mapped to some contiguous output memory address, and it's not suitable to print out the information as to how mergeable section pieces are mapped to an output section.