This is an archive of the discontinued LLVM Phabricator instance.

[ELF] Add .eh_frame pieces to map file
ClosedPublic

Authored by ruiu on Mar 6 2018, 10:55 AM.

Diff Detail

Repository
rL LLVM

Event Timeline

ruiu created this revision.Mar 6 2018, 10:55 AM

I agree that this change is simpler, but it also doesn't produce the same output as D42960. Part of the reason for the "complexity" in my change in D42960 was to try to prevent the map file output from getting too big/verbose.

However, this output is certainly more clear/explicit, if potentially rather verbose.

ruiu added a comment.Mar 6 2018, 11:22 AM

How much do you have by you patch compared to this one? Actually I didn't notice that you patch tries squashing contiguous pieces to reduce number of lines until I apply your patch and play with that because the patch didn't explain that at all... So it just looked complicated.

ruiu updated this revision to Diff 137246.Mar 6 2018, 12:50 PM
  • squash contiguous section pieces.
ruiu added a comment.Mar 6 2018, 12:51 PM

Turned out that squashing adjascent .eh_frame pieces before printing saves a lot of lines. When I used it agianst MySQL, it reduced the number of lines for .eh_frame in a map file by half. So we probably should do this.

grimar added a subscriber: grimar.Mar 7 2018, 5:25 AM

Apart from the typo and the value for the alignment, LGTM.

lld/ELF/MapFile.cpp
122 ↗(On Diff #137246)

Typo: adjuscent -> adjacent.

143 ↗(On Diff #137246)

Perhaps instead of 0 for the alignment, this could be the EhSectionPiece alignment which is Config->Wordsize?

ruiu added inline comments.Mar 14 2018, 2:09 PM
lld/ELF/MapFile.cpp
143 ↗(On Diff #137246)

I actually don't think so -- I believe the section itself is aligned, but each piece within a section doesn't have a notion of alignment.

This revision was not accepted when it landed; it landed in state Needs Review.Mar 14 2018, 2:21 PM
This revision was automatically updated to reflect the committed changes.

Looking at the EhFrameSection writing and finalize code, it would seem that
some kind of alignment is being applied. This aligning is also the reason
why for x86_64 the mapping of CIE/FDE's to the output is so fragmented,
because all input we have seen is 4-byte aligned, but LLD uses 8-byte
alignment for the output.

Cheers,
Andrew

Andrew Ng via Phabricator <reviews@reviews.llvm.org> writes:

andrewng added a comment.

Looking at the EhFrameSection writing and finalize code, it would seem that
some kind of alignment is being applied. This aligning is also the reason
why for x86_64 the mapping of CIE/FDE's to the output is so fragmented,
because all input we have seen is 4-byte aligned, but LLD uses 8-byte
alignment for the output.

Both gcc and clang produce an alignment of 8 for a trivial function:

[ 6] .eh_frame PROGBITS 0000000000000000 000078 000038 00 A 0 0 8

The reason for doing that in an unfortunate backwards compatibility
problem. If a section whose size is not a multiple of 8 is followed by a
section aligned to 8 bytes we would have a zero padding which would be
interpreted as the terminator.

We (MC) could produce .eh_frame whose sizes are always multiples of 8
but the alignment is set to 4, but no one ever bothered to implement
that.

Cheers,
Rafael