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: unassignedb...@nondot.org
Reporter: rafael.espind...@gmail.com
CC: gri...@accesssoftek.com, llvm-bugs@lists.llvm.org,
r...@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.
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
