<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>I've found a potential solution here: Use the gnu binutils
linker. It seems to be less picky than the sun linker about
alignment of the offending relocations. My sparc takes about 80
hours to build clang, so I'll know more about whether the next
bootstrap stage went well in about 70 hours.</p>
<p>Another workaround is to change clang to use:</p>
<p>.cfi_lsda 0, .Lexception0</p>
<p>Instead of:</p>
<p>.cfi_lsda 27, .Lexception0</p>
<p>for various relocations in the assembly. Setting LSDAEncoding to
dwarf::DW_EH_PE_absptr in
MCObjectFileInfo::initELFMCObjectFileInfo might be how one would
do this. But this isn't great for PIC. I guess the real fix
would be to change the integrated assembler to place the
relocations at aligned offsets.<br>
</p>
On 4/19/2018 3:28 PM, Dave Vitek via cfe-dev wrote:<br>
<blockquote type="cite"
cite="mid:47c66e2c-b643-d15c-9e20-ef490b0063d7@grammatech.com">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
Hi all, <br>
<br>
I have encountered some linker errors trying to build a small
64-bit sparc/solaris10 c++ test program using a freshly built
clang 6.0.0 on sparc/solaris10. I suspect either the compiler or
the integrated assembler is at fault. <br>
<br>
My clang can produce working 32-bit "hello world" C and C++
programs. It can produce working 64-bit C programs. However, it
cannot produce a 64-bit "hello world" C++ program. It appears to
be trying to place exception tables at misaligned addresses. I
don't know whether the exception-tableness or c++ness is important
or just happenstance. <br>
<br>
Here is my test program: <br>
<br>
#include <iostream> <br>
#include <string> <br>
#include <atomic> <br>
std::atomic<float> y(0.0f); <br>
int main() <br>
{ <br>
std::string x("foo\n"); <br>
std::cout << x << y << std::endl; <br>
return 0; <br>
} <br>
<br>
clang++ -m64 -o /tmp/foo /tmp/foo.cpp -latomic -v <br>
<br>
"/usr/ccs/bin/ld" -C -e _start -Bdynamic --dynamic-linker
/usr/lib/sparcv9/ld.so.1 -o /tmp/foo <i class="moz-txt-slash"><span
class="moz-txt-tag">/</span>export/home/dvitek/hermetictc/prest0/bin<span
class="moz-txt-tag">/</span></i>../lib64/crt1.o
/usr/lib/sparcv9/crti.o /usr/lib/sparcv9/values-Xa.o <i
class="moz-txt-slash"><span class="moz-txt-tag">/</span>export/home/dvitek/hermetictc/prest0/bin<span
class="moz-txt-tag">/</span></i>../lib64/crtbegin.o
-L/export/home/dvitek/hermetictc/prest0/bin/../lib64
-L/export/home/dvitek/hermetictc/prest0/bin -L/usr/lib/sparcv9/
-L/export/home/dvitek/hermetictc/gcc7/lib/sparcv9
/var/tmp/foo-5242ae.o -latomic -lstdc++ -lgcc_s -lc -lm <i
class="moz-txt-slash"><span class="moz-txt-tag">/</span>export/home/dvitek/hermetictc/prest0/bin<span
class="moz-txt-tag">/</span></i>../lib64/crtend.o
/usr/lib/sparcv9/crtn.o <br>
ld: fatal: relocation error: R_SPARC_DISP32: file
/var/tmp/foo-5242ae.o: symbol .gcc_except_table (section): offset
0xffffffff7c004245 is non-aligned <br>
ld: fatal: relocation error: R_SPARC_DISP32: file
/var/tmp/foo-5242ae.o: symbol .gcc_except_table (section): offset
0xffffffff7c004261 is non-aligned <br>
ld: fatal: relocation error: R_SPARC_DISP32: file
/var/tmp/foo-5242ae.o: symbol .gcc_except_table (section): offset
0xffffffff7c004295 is non-aligned <br>
ld: fatal: relocation error: R_SPARC_DISP32: file
/var/tmp/foo-5242ae.o: symbol .gcc_except_table (section): offset
0xffffffff7c0042dd is non-aligned <br>
ld: fatal: relocation error: R_SPARC_DISP32: file
/var/tmp/foo-5242ae.o: symbol .gcc_except_table (section): offset
0xffffffff7c004355 is non-aligned <br>
ld: fatal: relocation error: R_SPARC_DISP32: file
/var/tmp/foo-5242ae.o: symbol .gcc_except_table (section): offset
0xffffffff7c0043a1 is non-aligned <br>
ld: fatal: relocation error: R_SPARC_DISP32: file
/var/tmp/foo-5242ae.o: symbol .gcc_except_table (section): offset
0xffffffff7c0043d1 is non-aligned <br>
ld: fatal: relocation error: R_SPARC_DISP32: file
/var/tmp/foo-5242ae.o: symbol .gcc_except_table (section): offset
0xffffffff7c004449 is non-aligned <br>
<br>
There are 8 chunks of assembly--one for each link error--that look
about like this: <br>
<br>
.Lfunc_end2: <br>
.size main, .Lfunc_end2-main <br>
.cfi_endproc <br>
.section .gcc_except_table,#alloc <br>
.p2align 2 <br>
GCC_except_table2: <br>
.Lexception0: <br>
.byte 255 ! @LPStart Encoding = omit
<br>
.byte 0 ! @TType Encoding = absptr
<br>
.byte 41 ! @TType base offset <br>
.byte 3 ! Call site Encoding =
udata4 <br>
.byte 39 ! Call site table length <br>
.word .Ltmp0-.Lfunc_begin0 ! >> Call Site 1
<< <br>
.word .Ltmp1-.Ltmp0 ! Call between .Ltmp0
and .Ltmp1 <br>
.word .Ltmp2-.Lfunc_begin0 ! jumps to .Ltmp2 <br>
.byte 0 ! On action: cleanup <br>
.word .Ltmp3-.Lfunc_begin0 ! >> Call Site 2
<< <br>
.word .Ltmp8-.Ltmp3 ! Call between .Ltmp3
and .Ltmp8 <br>
.word .Ltmp9-.Lfunc_begin0 ! jumps to .Ltmp9 <br>
.byte 0 ! On action: cleanup <br>
.word .Ltmp8-.Lfunc_begin0 ! >> Call Site 3
<< <br>
.word .Lfunc_end2-.Ltmp8 ! Call between .Ltmp8
and .Lfunc_end2 <br>
.word 0 ! has no landing pad <br>
.byte 0 ! On action: cleanup <br>
.p2align 2 <br>
! -- End function <br>
<br>
<br>
Some data points: <br>
- If I compile the object file with g++ (which uses
/usr/ccs/bin/as) and then link it with clang++ things go smoothly.
<br>
- If I use -fno-exceptions with clang things go smoothly <br>
- If I don't use -m64 things go smoothly <br>
- clang is using the integrated assembler <br>
- clang is using /usr/ccs/bin/ld <br>
- clang was built using gcc 7.3 and is using gcc's libstdc++ <br>
- Historically, I've always used the sun assembler and linker when
building gcc toolchains on solaris <br>
- The sun assembler hates the dialect of assembly being produced
by clang <br>
- clang hates the (sun-style?) assembly that g++ produces <br>
- lld hates crt1.o, and isn't documented to work on this platform,
so I'm guessing it is a non-starter <br>
<br>
clang was built with -DLLVM_INCLUDE_TOOLS=bootstrap-only,
-DCLANG_DEFAULT_LINKER=/usr/ccs/bin/ld, various
component-disabling flags, and some fixes for uninteresting
compilation errors. <br>
<br>
Has anyone already encountered this problem? Failing that, any
suggestions for where to get started fixing the issue? Is this
worth pursuing or is it likely to be the first in a long series of
issues? <br>
<br>
- Dave<br>
<br>
PS<br>
I sent this message using the wrong account the first time.
Apologies if anyone receives a duplicate copy.<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
cfe-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>