Page MenuHomePhabricator

[ELF] Allow arbitrary code alignment in .eh_frame

Authored by phosek on Jul 28 2016, 9:36 PM.



According to the specification, CIE code alignment factor is an arbitrary unsigned LEB128 encoded value.

Diff Detail


Event Timeline

phosek updated this revision to Diff 66076.Jul 28 2016, 9:36 PM
phosek retitled this revision from to [ELF] Allow arbitrary code alignment in .eh_frame.
phosek updated this object.
phosek added a project: lld.
phosek added a subscriber: llvm-commits.
ruiu added a subscriber: ruiu.Jul 28 2016, 9:38 PM

Can you give me a pointer to the spec?

Even though the blog post from Ian Lance Taylor says that "... should always be 1 for .eh_frame." there is no such thing in the standard and both ld and gold allow arbitrary code alignment factor. Hence, there is no reason lld should enforce the value to be 1.

Furthermore, this breaks while linking objects on some platforms; for example the binutils assembler uses code alignment 4 when emitting the CFI on arm64 which is the most sensible thing to use, since instructions are always 4-byte aligned.

ruiu accepted this revision.Jul 28 2016, 9:43 PM
ruiu added a reviewer: ruiu.

LGTM. Thank you for the explanation. I believe this code was (accidentally) added as per the description that Ian Lance Taylor wrote.

This revision is now accepted and ready to land.Jul 28 2016, 9:43 PM
This revision was automatically updated to reflect the committed changes.
ruiu added a comment.Jul 28 2016, 9:52 PM

On second thought, is it okay to just discard the information here? I'm wondering if we need to respect specified alignment requirements.

ed added a subscriber: ed.Aug 11 2016, 4:40 AM

I just experienced this error while trying to build glib for i686.

It looks like this change is not part of LLD 3.9.0rc1. Would it make sense to merge this into the release branch?

ed added a comment.Aug 11 2016, 6:25 AM
In D22954#512472, @ed wrote:

I just experienced this error while trying to build glib for i686.

Disregard that. That was with an older version of Clang that generated such .o files (r269026). The output generated by Clang 3.9.0rc1 doesn't trigger such an error from LLD.