[MC] Invalid GOTOFF relocation in shared library objects

[llvmbot]

Bugzilla Link	9693
Resolution	FIXED
Resolved on	Aug 10, 2011 22:18
Version	trunk
OS	Linux
Blocks	llvm/llvm-bugzilla-archive#10638
Reporter	LLVM Bugzilla Contributor
CC	@DimitryAndric,@efriedma-quic

Extended Description

On freenode#winehackers, Austin English reported the following while building Wine with latest trunk LLVM/Clang:

austin@aw21 ~/src/wine-clang/dlls/msvcrt $ make
../../tools/winegcc/winegcc -B../../tools/winebuild --sysroot=../.. -fasynchronous-unwind-tables -shared ./msvcrt.spec console.o cpp.o cppexcept.o ctype.o data.o dir.o environ.o errno.o except.o exit.o file.o heap.o locale.o lock.o main.o math.o mbcs.o misc.o process.o scanf.o string.o thread.o time.o undname.o wcs.o rsrc.res -o msvcrt.dll.so -ladvapi32 -luser32 -Wb,-dadvapi32 -Wb,-duser32 ../../libs/port/libwine_port.a
/usr/lib/gcc/i686-pc-linux-gnu/4.4.5/../../../../i686-pc-linux-gnu/bin/ld: math.o: relocation R_386_GOTOFF against undefined symbol `cos@@GLIBC_2.0' can not be used when making a shared object
/usr/lib/gcc/i686-pc-linux-gnu/4.4.5/../../../../i686-pc-linux-gnu/bin/ld: final link failed: Bad value
clang: error: linker command failed with exit code 1 (use -v to see invocation)
winegcc: clang failed
make: *** [msvcrt.dll.so] Error 2

Looks like the ELF writer is generating GOTOFF relocations when it shouldn't be (i.e. in PIC objects).

I'll try to get him to reduce this to something you can use.

[llvmbot]

Thanks. A .ii should be good, a .s even better (assuming the problem is in the integrated assembler).

[llvmbot]

assembly file
It's failing on math.c. I've attached math.s, let me know if you need anything else.

[llvmbot]

Did some more testing, does not occur at -O0, but does occur at -O1 and -O2. This is the case in 2.9 and in trunk (r130866). Furthermore, occurs with or without the integrated assembler.

I'll attach a preprocessed C file.

[llvmbot]

preprocessed clang file
clang -E -I. -I. -I../../include -I../../include -D__WINESRC__ -D_MT -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -std=gnu89 -g -O1 -no-integrated-as math.c &> ~/math.i

[llvmbot]

preprocessed gcc file
gcc -E -I. -I. -I../../include -I../../include -D__WINESRC__ -D_MT -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -std=gnu89 -g -O1 math.c &> ~/math_gcc.i

[llvmbot]

I was able to trigger the bug with just:

#include <math.h>

double foo(double x)
{
return sin(x);
}

=======

though I haven't quite been able to get a testcase that doesn't depend on Wine yet. It's optimization related, doesn't occur at -O0, but does at -O1, but I haven't yet found a list of what -O1 enables to narrow it down..

[DimitryAndric]

We are seeing the same here on FreeBSD with several ports, but typically
only when users use '-march=native' to compile.

After some experimentation, I ended up with exactly the same wrapper as
in comment 6. The trick is that you need at least:

• -fPIC
• -O1 or higher
• last but not least: -target-cpu pentium4 or higher

E.g. using a "high" CPU:

clang -cc1 -triple i386-unknown-freebsd9.0 -S -pic-level 2 -target-cpu
pentium4 -O2 wrapper.c

results in:

foo:
calll .L0$pb
.L0$pb:
popl %eax
.Ltmp0:
addl $GLOBAL_OFFSET_TABLE+(.Ltmp0-.L0$pb), %eax
leal sin@GOTOFF(%eax), %eax
jmpl *%eax

whereas using a "lower" CPU:

clang -cc1 -triple i386-unknown-freebsd9.0 -S -pic-level 2 -target-cpu
i686 -O1 wrapper.c

results in:

foo:
pushl %ebx
subl $8, %esp
calll .L0$pb
.L0$pb:
popl %ebx
.Ltmp0:
addl $GLOBAL_OFFSET_TABLE+(.Ltmp0-.L0$pb), %ebx
fldl 16(%esp)
fstpl (%esp)
calll sin@PLT
addl $8, %esp
popl %ebx
ret

The former command line later leads to a linking error "relocation
R_386_GOTOFF against undefined symbol", as mentioned at the start of
this PR. The latter works OK.

Apparently the tail-call optimization is triggered when using "high"
CPUs, but apparently something else than GOTOFF(%eax) must be used.
I could not get gcc 4.6 to produce a tail call, so I have no idea what
it should be. :)

[efriedma-quic]

r137292.

[llvmbot]

r137292.

clang version 3.0 (trunk 137293)

works for wine at -O1/-O2 :)