[llvm-bugs] [Bug 25942] New: Try to better optimize .eh_frame
llvm-bugs at lists.llvm.org
Thu Dec 24 13:03:15 PST 2015
Bug ID: 25942
Summary: Try to better optimize .eh_frame
Component: new bugs
Assignee: unassignedbugs at nondot.org
Reporter: rafael.espindola at gmail.com
CC: grimar at accesssoftek.com, llvm-bugs at lists.llvm.org,
ruiu at google.com
The .eh_frame sections that MC produces always have an alignment of 8. This is
* Some .eh_frame sections can actually require such alignment (they have a 8
* A 32 bit zero after a FDE/CIE is interpreted as a terminator.
The net result is that a simple linker might add padding when concatenating a
.eh_frame section with alignment of 8 if it follows one that is not a multiple
of 8 bytes.
To make sure every .eh_frame is a multiple of 8 bytes, we use
EmitValueToAlignment which sets the section alignment.
This solves the problem for simple linkers, but causes problem for linker that
optimize .eh_frame. Now they don't know the alignment requirement of each
cie/fde and have to compensate for it, sometimes making the output .eh_frame
section larger than with a simple linker :-(
It might be possible to do better. Some options
* Assume that all linkers these days process .eh_frame specially and don't pad
the last FDE to make the section a multiple of 8 bytes.
* Still make it a multiple of 8 bytes, but be careful to not increase the
With that lld could then remember the alignment of each fde/cie.
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-bugs