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>