[llvm][patch] Adjust behavior of FDE cross-section relocs for targets that don't support abs-differences.

Iain Sandoe iain at codesourcery.com
Tue Dec 3 07:59:55 PST 2013


Hi, 
(I hope I have directed this to the correct reviewers)

At the dev. conf. David reported to me that EH was not working on ppc-darwin8.  Once we checked a few more platforms, it turns out it's not working with any ld64 < 97.17 (so OSX < 10.6 on both x86/ppc).

The reason is that the older ld/ld64 versions require proper scattered relocs for expressions in CIE/FDE symbol refs that cross section boundaries.

Later versions of the ld64 allow that these may be replaced by an absolute difference***

AFAIK, this behaviour is specific to Darwin/OSX (and ld64 >= 97.17), I suspect that any other target that elected to use a non-trivial FDE symbol encoding would likely be surprised by the abs values.  However, these are hardwired in MCDwarf.cpp, as of now.

NOTE1: in general, this would not cause a linkage error for the target - 'just' a failure to unwind at runtime.
NOTE2: it also seems that the abs-ification is not done even for x86-64-darwin12 for compact unwind.

The solution I am proposing is to introduce a "DwarfFDESymbolsUseAbsDiff" boolean value in MCAsmInfo and to use that to control this behaviour.  In the patch, this is only switched on for X86 Darwin/OSX & for OSX >= 10.6.  It should really be contingent on -target-linker-version >= 97.17, but this information is not yet passed to the target.

With the patch EH works on *-darwin9 with the native linker (and still emits the same set of relocs on darwin12).

Is this a reasonable solution?
Iain

*** P.S.
I assume that these extra hoops and inconsistencies (and presumably matching ones in ld64) are really worthwhile?
I.E. that there is some measurable performance gain?
(if not, we could just elect to emit the relocs and drop this special casing).

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: llvm-eh-fde-relocs-diff-v1.txt
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131203/9b53d407/attachment.txt>
-------------- next part --------------




More information about the llvm-commits mailing list