[LLVMdev] 64-bit binaries and the Solaris linker

[ep]

Hello devs,
   llvm+clang doesn't emit .s/.o files which can be linked
successfully, on a 64-bit compilation, with the Solaris linker ld(1).

The problem lies in the way the .eh_frame section header is created.
llvm+clang creates it with SHT_PROGBITS and SHT_ALLOC|SHT_WRITE, while
the Solaris linker expects a SHT_AMD64_UNWIND section with SHT_ALLOC
only permissions [1]. Simple example follows:

root at markuse:/work/llvm/llvm/Debug+Asserts/bin# ./clang -o h hello.c -m64
ld: fatal: file /tmp/cc-LNa4VK.o: section [6].eh_frame: section type
is SHT_PROGBITS: expected SHT_AMD64_UNWIND
collect2: ld returned 1 exit status
clang: error: linker (via gcc) command failed with exit code 1 (use -v
to see invocation)
root at markuse:/work/llvm/llvm/Debug+Asserts/bin# ./clang -v -o h hello.c -m64

Emitted .s file:

[...]
       .section        .eh_frame,"aw", at progbits
.LEH_frame0:
.Lsection_eh_frame0:
.Leh_frame_common0:
[...]


I've made a quick patch to llvm to emit a proper section header and
successfully got llvm+clang compile binaries on Solaris. Patch is
attached. Note that the attached patch is not meant at all to be a
final patch, since it would quite clearly break any other linker that
expects a SHT_PROGBITS section. It is just there to test the potential
fix (and to give me something working with Solaris). Compilation with
this applied goes smoothly:

root at markuse:/work/llvm/llvm/Debug+Asserts/bin#
/usr/llvm/llvm-2.8-solfix/bin/clang -o h hello.c -m64
root at markuse:/work/llvm/llvm/Debug+Asserts/bin#

[...]
        .section        .eh_frame,"a", at unwind
.LEH_frame0:
.Lsection_eh_frame0:
.Leh_frame_common0:
[...]


Said that, I'm more than happy to work out a better patch, but I was
looking first for some feedback on this as:

- would it be acceptable to have system-specific output depending on
the target linker chain? (and have this likely OS/arch dependent, in
this specific case, Solaris+AMD64).
- was a similar problem already faced in other environments and what
was the solution adopted there? (pointer to the code would be great so
that I could keep mine coherent with that).
- any other point/problem/detail :-)

Thanks!

              -  Enrico



[1] More about the putback that introduced a stricter behavior with
the linker here:
http://static.opensolaris.org/on/flagdays/pages/20100325134609.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: amd64_unwind.diff
Type: application/octet-stream
Size: 2386 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101027/0d45796e/attachment.obj>