[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


            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