Re: A glibc dynamic linker or gld bug?

[Geoff Keating <geoffk@ozemail.com.au>]

> 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>