This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
Re: A glibc dynamic linker or gld bug?
- To: hjl@lucon.org
- Subject: Re: A glibc dynamic linker or gld bug?
- From: Geoff Keating <geoffk@ozemail.com.au>
- Date: Mon, 5 Jul 1999 14:55:51 +1000
- CC: drepper@cygnus.com, ian@cygnus.com, binutils@sourceware.cygnus.com, libc-hacker@sourceware.cygnus.com, jgg@ualberta.ca
- References: <19990704205206.7C71E57B9@ocean.lucon.org>
> Mailing-List: contact libc-hacker-help@sourceware.cygnus.com; run by ezmlm
> Date: Sun, 4 Jul 1999 13:52:06 -0700 (PDT)
> Cc: ian@cygnus.com (Ian Lance Taylor), binutils@sourceware.cygnus.com,
> libc-hacker@sourceware.cygnus.com (GNU C Library), jgg@ualberta.ca
> From: hjl@lucon.org (H.J. Lu)
>
> Hi,
>
> Here is a testcase for a glibc dynamic linker or gld bug:
>
> # make
> cc -shared -o libfoo.so -fPIC -O -g foo.c
> cc -o bar1.o -c -fPIC -O -g bar.c
> cc -o foo1 -O -g libfoo.so main.c bar1.o -Wl,-rpath,.
> cc -o bar2.o -c -O -g bar.c
> cc -o foo2 -O -g libfoo.so main.c bar2.o -Wl,-rpath,.
> for f in foo1 foo2; do echo "Running: $f"; ./$f; \
> if [ $? != 0 ]; then echo Failed; fi; done
> Running: foo1
> Failed
> Running: foo2
>
> The same testcase ran fine under Solaris/x86 and Solaris/Sparc even
> with the GNU ld. I suspect the bug is in the weak symbol handling
> in the glibc dynamic linker. Since the Solaris dynamic linker treats
> weak as strong, the bug may also be in gld.
I can't reproduce this on ppc with binutils snapshot from 981225, and
the released 2.1.1 ld.so.
I suspect there is a (possibly machine-specific) bug in your ld; in
fact, I would suspect the problem is in linking PIC code into
executables.
On my machine, the dynamic linker has no influence whatsoever on
whether 'abort' is called in foo1 or foo2. The complete list of
relocations generated is:
[geoffk@geoffk shared2]$ objdump -R foo1
foo1: file format elf32-powerpc
DYNAMIC RELOCATION RECORDS
OFFSET TYPE VALUE
018406d4 R_PPC_JMP_SLOT abort
018406dc R_PPC_JMP_SLOT __libc_start_main
and it's the same for foo2.
This is correct. There is no way that a weak symbol defined in an
executable can be overriden by anything else, so there should be no
relocations referring to it.
--
Geoffrey Keating <geoffk@ozemail.com.au>