Versioning mess proved!!!

[Geoff Keating]

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