Re: preloading newly created objects

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

> From: Ulrich Drepper <drepper@cygnus.com>
> Date: 08 Sep 1998 11:25:07 -0700

> Please be careful with the current development version.  If you create
> a shared object and try to preload it to a binary linked with glibc
> 2.0 it does not work.  I'm currently investigating this.

I had a similar bug on ppc, and tracked the ppc version down to the
change to __gmon_start__.  What happened was that the linker was
seeing a weak symbol that wasn't defined in any shared libraries, and
not generating a PLT entry for it---but it was generating a GOT entry.
For instance, the .init section of an old executable I have has:

/* Load the address of __gmon_start__ from the GOT */
 18103b8:       80 09 00 0c     lwz     r0,12(r9)
/* Check to see if it is NULL.  */
 18103bc:       2c 80 00 00     cmpwi   cr1,r0,0
 18103c0:       41 86 00 08     beq     cr1,0x18103c8
/* Branch to location 0 if it is not NULL.  This is the wrong
   instruction.  */
 18103c4:       4a 7e fc 3d     bl      0x0
/* .init continues with some constructors.  */
 18103c8:       4b ff ff 71     bl      0x1810338

With corresponding relocations:

01851e78 R_PPC_GLOB_DAT    __gmon_start__

Now, if something should be so impolite as to define __gmon_start__,
this code will branch to location 0 and segfault.

Current binutils is fixed to have this work on ppc---it properly
points the branch to a PLT entry.  I've added a workaround for the bug
to my 'fix961212' utility, basically it just changes the name of
__gmon_start__ to something that no-one should define.


Of course, your bug may well be something completely different.
Notice how this only happens with non-versioned shared objects; for
instance, libSegFault.so (convenient :-).



-- 
Geoffrey Keating <geoffk@ozemail.com.au>