tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] Overflows in the dynamic linker on x86_64 when using


From: Petr Skočík
Subject: Re: [Tinycc-devel] Overflows in the dynamic linker on x86_64 when using a tcc-built shared library along with others
Date: Tue, 3 Jul 2018 09:26:51 +0200

I tracked down what was causing the "./a.out: Symbol `fstat' causes overflow in R_X86_64_PC32 relocation" message (and I suppose the others as well).

My build script attempts to link my executables with my project's dynamic lib (unless directed otherwise) and then a static version of the same lib before linking in external libs (the idea is to have a generic recipe that provides for the possibility that some of my project's executables might want to refer to project symbols that aren't exported in the shared lib).
It seems it is this double linking ( `tcc something... liblib.so liblib.a` ), compounded with something in the glibc definition of
fstat, that causes the problem on tcc.

MCVE:

#!/bin/sh -eu
cat > liblib.c <<EOF
#include <sys/stat.h>
void f(void) { struct stat sb; fstat(0, &sb); }
EOF
cat > main.c <<EOF
int main() { extern void f(); f(); return 0; }
EOF
: ${CC:=tcc}
$CC liblib.c -fPIC -c; ar rcs liblib.a liblib.o; $CC -o liblib.so liblib.o -shared 
$CC main.c $PWD/liblib.so liblib.a #uncommenting liblib.a removes the error
LD_LIBRARY_PATH=$PWD ./a.out

In the above reproducer, liblib.a should be ignored because it's not resolving any undefined references, but instead it appears to be causing the error message.

Regards,
Petr Skocik


On Mon, Jul 2, 2018 at 1:16 AM Michael Matz <address@hidden> wrote:
Hi,

On Thu, 28 Jun 2018, Petr Skocik wrote:

> Symbol `__dso_handle' causes overflow in R_X86_64_PC32 relocation
> Symbol `fstatat' causes overflow in R_X86_64_PC32 relocation
> Symbol `fstat' causes overflow in R_X86_64_PC32 relocation
> Symbol `mknod' causes overflow in R_X86_64_PC32 relocation
> Symbol `pthread_atfork' causes overflow in R_X86_64_PC32 relocation

Indeed.  TCC doesn't link with crtbegin.o (or crtbeginS.o) coming from
GCC, and hence doesn't provide the hack symbol __dso_handle (which
pthread_atfork in glibc needs).  This is another case of an
interdependency between glibc and compiler specifics.

> I tried to make an MCVE (minimal, complete, verifiable example) and this one
> should do it:

Thanks.  There's a work around for the pthread_atfork problem: add this
definition to one source file for each shared library/executable that
contains a call to pthread_atfork:

   void * __dso_handle __attribute((visibility("hidden"))) = &__dso_handle;

e.g. in your testcase, add it to liblib.c .  Eventually we probably want
to create this symbol automatically from TCC on glibc systems, until then
you can use the above.

That fstat/fstatat/mknod have overflows as well might have multiple
reasons: on glibc systems all three functions have something in common:
they are defined in the libc_nonshared.a archive, which normally should
have been included via libc.so (a linker script, not a normal softlink to
the real shared lib).  You can check with -vvv which should list that
library to be included.  No matter what I can't reproduce that problem by
e.g. adding a call to fstatat into your reproducer for the dso_handle
problem, so if you can provide one for e.g. fstatat as well...

> If this is a bad place to post such bug reports, please let me know. 
> (Should  I post bug reports on
> https://savannah.nongnu.org/bugs/?group=tinycc or elsewhere instead?) 

Many people here don't have a bugzilla account there and so
don't monitor it; it seems better to write here.


Ciao,
Michael._______________________________________________
Tinycc-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

reply via email to

[Prev in Thread] Current Thread [Next in Thread]