This is the mail archive of the
libc-hacker@sourceware.cygnus.com
mailing list for the glibc project.
Re: preloading newly created objects
- To: drepper@cygnus.com
- Subject: Re: preloading newly created objects
- From: Geoff Keating <geoffk@ozemail.com.au>
- Date: Wed, 9 Sep 1998 19:12:19 +1000
- CC: libc-hacker@cygnus.com
- References: <r2n28a1myk.fsf@happy.cygnus.com>
> 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>