[llvm-bugs] [Bug 25942] New: Try to better optimize .eh_frame
via llvm-bugs
llvm-bugs at lists.llvm.org
Thu Dec 24 13:03:15 PST 2015
https://llvm.org/bugs/show_bug.cgi?id=25942
Bug ID: 25942
Summary: Try to better optimize .eh_frame
Product: new-bugs
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
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
Classification: Unclassified
The .eh_frame sections that MC produces always have an alignment of 8. This is
some because
* Some .eh_frame sections can actually require such alignment (they have a 8
byte pointer).
* 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
section alignment.
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...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20151224/834376e1/attachment.html>
More information about the llvm-bugs
mailing list