[LLVMbugs] [Bug 4724] New: "relocation R_X86_64_PC32 against undefined symbol" building C++ shared libraries

[bugzilla-daemon at cs.uiuc.edu]

http://llvm.org/bugs/show_bug.cgi?id=4724

           Summary: "relocation R_X86_64_PC32 against undefined symbol"
                    building C++ shared libraries
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: ssen at apple.com
                CC: llvmbugs at cs.uiuc.edu


I'm trying to build llvm/llvm-gcc-4.2 trunk (r79073) on Ubuntu 9.0.4 (x86_64)

libstdc++-v3 fails to link with:
/usr/bin/ld: .libs/bitmap_allocator.o: relocation R_X86_64_PC32 against symbol
`__gxx_personality_v0' can not be used when making a shared object; recompile
with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status


I managed to reduce this to something fairly simple (i think the difference in
mesage is because libstdc++.so actually provides the named symbol):

$ cat foo.cc
extern void foo(void);

void bar(void) throw() {
  foo();
}
$ ./gcc/xgcc -Bgcc -c foo.cc -fPIC
$ /usr/bin/g++ -shared -o foo.so foo.o
/usr/bin/ld: foo.o: relocation R_X86_64_PC32 against undefined symbol
`__gxx_personality_v0@@CXXABI_1.3' can not be used when making a shared object;
recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
$ g++ -c foo.cc -fPIC
$ /usr/bin/g++ -shared -o foo.so foo.o
$ 

Based on looking at the assembly, it looks like bad EH frame data, where
llvm-g++ is creating:
.LEH_frame1:
.Lsection_eh_frame1:
.Leh_frame_common1:
        .long   .Leh_frame_common_end1-.Leh_frame_common_begin1
.Leh_frame_common_begin1:
        .long   0x0
        .byte   0x1
        .asciz  "zPLR"
        .uleb128        1
        .sleb128        -8
        .byte   0x10
        .uleb128        7
        .byte   0x1B
        .long   __gxx_personality_v0-.

The ".long" creates a 32-bit relocation in a 64-bit ELF object, which can't be
linked into a shared library because the difference might be greater than
32-bits.

g++-4.3.3 creates:
        .uleb128 0x7
        .byte   0x9b
        .long   DW.ref.__gxx_personality_v0-.
        .byte   0x1b
...
.LEFDE1:
        .hidden DW.ref.__gxx_personality_v0
        .weak   DW.ref.__gxx_personality_v0
        .section       
.data.DW.ref.__gxx_personality_v0,"awG", at progbits,DW.ref
.__gxx_personality_v0,comdat
        .align 8
        .type   DW.ref.__gxx_personality_v0, @object
        .size   DW.ref.__gxx_personality_v0, 8
DW.ref.__gxx_personality_v0:
        .quad   __gxx_personality_v0


Using -fno-exceptions does eliminate the issue, which reinforces bad EH data


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.