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