[cfe-dev] sparcv9 .gcc_except_table (section): offset (odd number) is non-aligned

[Dave Vitek via cfe-dev]

Hi all,

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.

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.

Here is my test program:

#include <iostream>
#include <string>
#include <atomic>
std::atomic<float> y(0.0f);
int main()
{
     std::string x("foo\n");
     std::cout << x << y << std::endl;
     return 0;
}

clang++ -m64 -o /tmp/foo /tmp/foo.cpp -latomic -v

  "/usr/ccs/bin/ld" -C -e _start -Bdynamic --dynamic-linker 
/usr/lib/sparcv9/ld.so.1 -o /tmp/foo 
/export/home/dvitek/hermetictc/prest0/bin/../lib64/crt1.o 
/usr/lib/sparcv9/crti.o /usr/lib/sparcv9/values-Xa.o 
/export/home/dvitek/hermetictc/prest0/bin/../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 
/export/home/dvitek/hermetictc/prest0/bin/../lib64/crtend.o 
/usr/lib/sparcv9/crtn.o
ld: fatal: relocation error: R_SPARC_DISP32: file /var/tmp/foo-5242ae.o: 
symbol .gcc_except_table (section): offset 0xffffffff7c004245 is 
non-aligned
ld: fatal: relocation error: R_SPARC_DISP32: file /var/tmp/foo-5242ae.o: 
symbol .gcc_except_table (section): offset 0xffffffff7c004261 is 
non-aligned
ld: fatal: relocation error: R_SPARC_DISP32: file /var/tmp/foo-5242ae.o: 
symbol .gcc_except_table (section): offset 0xffffffff7c004295 is 
non-aligned
ld: fatal: relocation error: R_SPARC_DISP32: file /var/tmp/foo-5242ae.o: 
symbol .gcc_except_table (section): offset 0xffffffff7c0042dd is 
non-aligned
ld: fatal: relocation error: R_SPARC_DISP32: file /var/tmp/foo-5242ae.o: 
symbol .gcc_except_table (section): offset 0xffffffff7c004355 is 
non-aligned
ld: fatal: relocation error: R_SPARC_DISP32: file /var/tmp/foo-5242ae.o: 
symbol .gcc_except_table (section): offset 0xffffffff7c0043a1 is 
non-aligned
ld: fatal: relocation error: R_SPARC_DISP32: file /var/tmp/foo-5242ae.o: 
symbol .gcc_except_table (section): offset 0xffffffff7c0043d1 is 
non-aligned
ld: fatal: relocation error: R_SPARC_DISP32: file /var/tmp/foo-5242ae.o: 
symbol .gcc_except_table (section): offset 0xffffffff7c004449 is 
non-aligned

There are 8 chunks of assembly--one for each link error--that look about 
like this:

.Lfunc_end2:
         .size   main, .Lfunc_end2-main
         .cfi_endproc
         .section        .gcc_except_table,#alloc
         .p2align        2
GCC_except_table2:
.Lexception0:
         .byte   255                     ! @LPStart Encoding = omit
         .byte   0                       ! @TType Encoding = absptr
         .byte   41                      ! @TType base offset
         .byte   3                       ! Call site Encoding = udata4
         .byte   39                      ! Call site table length
         .word   .Ltmp0-.Lfunc_begin0    ! >> Call Site 1 <<
         .word   .Ltmp1-.Ltmp0           !   Call between .Ltmp0 and .Ltmp1
         .word   .Ltmp2-.Lfunc_begin0    !     jumps to .Ltmp2
         .byte   0                       !   On action: cleanup
         .word   .Ltmp3-.Lfunc_begin0    ! >> Call Site 2 <<
         .word   .Ltmp8-.Ltmp3           !   Call between .Ltmp3 and .Ltmp8
         .word   .Ltmp9-.Lfunc_begin0    !     jumps to .Ltmp9
         .byte   0                       !   On action: cleanup
         .word   .Ltmp8-.Lfunc_begin0    ! >> Call Site 3 <<
         .word   .Lfunc_end2-.Ltmp8      !   Call between .Ltmp8 and 
.Lfunc_end2
         .word   0                       !     has no landing pad
         .byte   0                       !   On action: cleanup
         .p2align        2
                                         ! -- End function


Some data points:
- If I compile the object file with g++ (which uses /usr/ccs/bin/as) and 
then link it with clang++ things go smoothly.
- If I use -fno-exceptions with clang things go smoothly
- If I don't use -m64 things go smoothly
- clang is using the integrated assembler
- clang is using /usr/ccs/bin/ld
- clang was built using gcc 7.3 and is using gcc's libstdc++
- Historically, I've always used the sun assembler and linker when 
building gcc toolchains on solaris
- The sun assembler hates the dialect of assembly being produced by clang
- clang hates the (sun-style?) assembly that g++ produces
- lld hates crt1.o, and isn't documented to work on this platform, so 
I'm guessing it is a non-starter

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.

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?

- Dave

PS
I sent this message using the wrong account the first time. Apologies if 
anyone receives a duplicate copy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180419/2f3b8057/attachment.html>