This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: Versioning mess proved!!!
> From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
> Date: Mon, 2 Oct 2000 00:05:12 +0200
> the zlib.so compiled against glibc-2.1.3:
> [fsirl@enzo:/cvsx/rawhide/zlib-1.1.3]$ objdump -R /usr/lib/libz.so|grep gmon
> 0001debc R_PPC_JMP_SLOT __gmon_start__
>
> the zlib.so compiled against glibc-2.1.94:
> [fsirl@enzo:/cvsx/rawhide/zlib-1.1.3]$ objdump -R
> ../BUILD/zlib-1.1.3/libz.so|grep gmon
> 0001e994 R_PPC_GLOB_DAT __gmon_start__
>
> the zlib example compiled against glibc-2.1.94 and
> zlib.so-compiled-against-2.1.3:
> [fsirl@enzo:/cvsx/rawhide/zlib-1.1.3]$ objdump -R example|grep gmon
> 10012ee8 R_PPC_GLOB_DAT __gmon_start__
> 10013104 R_PPC_JMP_SLOT __gmon_start__
>
> And I guess this double relocation is the culprit then?
Nope. The other two should have two relocations too.
I expect the code that calls __gmon_start__ looks like:
lwz r3,__gmon_start__@got(r31)
cmpwi r3,0
beq L1234
bl __gmon_start__@plt
L1234:
you should get a R_PPC_GLOB_DAT for the `lwz', and the `bl' should be
relocated to branch to a PLT entry which has a R_PPC_JMP_SLOT
relocation. (I'm not sure that this should happen in executables, but
there's no particular reason why not.)
--
- Geoffrey Keating <geoffk@cygnus.com>