Versioning mess proved!!!
Franz Sirl
Franz.Sirl-kernel@lauterbach.com
Tue Oct 3 12:25:00 GMT 2000
On Tue, 03 Oct 2000, Christian Iseli wrote:
> Hi,
>
> Franz.Sirl-kernel@lauterbach.com said:
> > $ LD_LIBRARY_PATH=./213/ LD_BIND_NOW=1 ./tA
> > 0x10010818
> > $ LD_LIBRARY_PATH=./22/ LD_BIND_NOW=1 ./tA
> > 0x10010818
> > Segmentation fault (core dumped)
> >
> > The testcase works on both glibc-2.1.9x and gcc-2.1.3 systems and
> > illustrates the same fault I see with zlib, namely that during the
> > execution the first word of foo() gets relocated to an absolute
> > branch to 0. This leads to a nice segfault then.
>
> Tried it on alpha, both under glibc-2.1.2 and mainline glibc-2.1.94:
> # LD_LIBRARY_PATH=./213/ LD_BIND_NOW=1 ./tA
> 0x20000122a90
> # LD_LIBRARY_PATH=./22/ LD_BIND_NOW=1 ./tA
> (nil)
If you change the last compile command to:
gcc tA-22.c -fpic -Wl,-v -L213 -ltB -o tA
(added -fpic), what does objdump/readelf tell you? I get:
[fsirl@enzo:~]$ objdump -xTR tA|grep foo
10010920 w F *UND* 0000001c foo
10010920 w DF *UND* 0000001c foo
100107fc R_PPC_GLOB_DAT foo
10010920 R_PPC_JMP_SLOT foo
[fsirl@enzo:~]$ readelf -a tA|grep foo
100107fc 00b14 R_PPC_GLOB_DAT 10010920 foo +
0
10010920 00b15 R_PPC_JMP_SLOT 10010920 foo +
0
11: 10010920 28 FUNC WEAK DEFAULT UND foo
96: 10010920 28 FUNC WEAK DEFAULT UND foo
Franz.
More information about the Libc-alpha
mailing list