This patch is a simplified version of https://reviews.llvm.org/D42960
written by Andrew Ng.
Details
Diff Detail
- Build Status
Buildable 15733 Build 15733: arc lint + arc unit
Event Timeline
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.
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.
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.
lld/ELF/MapFile.cpp | ||
---|---|---|
143 | 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. |
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
Typo: adjuscent -> adjacent.