This is the mail archive of the libc-hacker@sourceware.cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Damaged PPC_REL24 handling


> Date: Sun, 15 Nov 1998 20:15:56 -0500
> From: Daniel Jacobowitz <drow+@cs.cmu.edu>
> Mail-Followup-To: libc-alpha@gnu.org
> 
> On Mon, Nov 16, 1998 at 12:12:21PM +1100, Geoff Keating wrote:
> > No, the previous test is right (if a little obscure).  The field is
> > sign-extended, that's how you branch to addresses earlier in the code.
> > 
> > It might be a bit less obscure as
> > 'delta < -0x04000000 || delta >= 0x04000000', or whatever
> > the correct bounds are.
> > 
> > > symbol name:
> > > ic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b1i0Uic
> > > 
> > > loadbase sym->st_value reloc->r_addend
> > > 0178e000 00000000      00014664
> > > 
> > 
> > That looks like a perfectly reasonable loadbase to me for a shared
> > library being loaded under an application that starts at address 0x01800000.
> > 
> > Generally, in working systems, there should be no R_PPC_REL24 relocs
> > in either applications (they get turned into PLT entries by ld) or in
> > shared libraries (they get turned into PLT entries by gcc when you
> > compile with -fpic).  They are only implemented for compatibility with
> > shared libraries that are not compiled as PIC.  Making non-PIC shared
> > libraries work takes careful attention to the memory map.
> 
> The bug was identified; thanks to Richard Henderson, we just discovered
> that libstdc++ has not been built as PIC on powerpc for at least a very
> long time.  That's where the REL24's were coming from.

I'd still like to see the output if you set LD_TRACE_LOADED_OBJECTS to
1, if you can generate it.  There's a chunk of code in ld.so that
tries to arrange the memory map so that non-PIC shared objects do
work, and it would be interesting to see if and how it's
failing---it's an efficiency issue for PIC code too.  I have it
working properly on my machine, but that's mklinux and the monolithic
kernel is probably different.

Ideally, all the shared libraries should be mapped just below where
the executable starts, like this:

 [geoffk@geoffk geoffk]$ LD_TRACE_LOADED_OBJECTS=1 emacs
        libXaw3d.so.6 => /usr/X11R6.3/lib/libXaw3d.so.6 (0x01755000)
        libXmu.so.6 => /usr/X11R6.3/lib/libXmu.so.6 (0x016f2000)
        libXt.so.6 => /usr/X11R6.3/lib/libXt.so.6 (0x01657000)
        libSM.so.6 => /usr/X11R6.3/lib/libSM.so.6 (0x015ff000)
        libICE.so.6 => /usr/X11R6.3/lib/libICE.so.6 (0x0159c000)
        libXext.so.6 => /usr/X11R6.3/lib/libXext.so.6 (0x01540000)
        libX11.so.6 => /usr/X11R6.3/lib/libX11.so.6 (0x01446000)
        libncurses.so.4 => /usr/lib/libncurses.so.4 (0x013b2000)
        libm.so.6 => /lib/libm.so.6 (0x01336000)
        libc.so.6 => /lib/libc.so.6 (0x011fa000)
        /lib/ld.so.1 => /lib/ld.so.1 (0x2aaab000)

But sometimes it doesn't work, for instance because there isn't room:

[geoffk@geoffk geoffk]$ LD_LIBRARY_PATH=/usr/lib/netscape \
> LD_TRACE_LOADED_OBJECTS=1 /usr/lib/netscape/netscape-navigator
        libSM.so.6 => /usr/X11R6.3/lib/libSM.so.6 (0x001a8000)
        libICE.so.6 => /usr/X11R6.3/lib/libICE.so.6 (0x00145000)
        libXmu.so.6 => /usr/X11R6.3/lib/libXmu.so.6 (0x000e2000)
        libXpm.so.4 => /usr/X11R6.3/lib/libXpm.so.4 (0x00085000)
        libXext.so.6 => /usr/X11R6.3/lib/libXext.so.6 (0x2ab04000)
        libX11.so.6 => /usr/X11R6.3/lib/libX11.so.6 (0x2ab50000)
        libdl.so.2 => /lib/libdl.so.2 (0x2ac3a000)
        libc.so.6 => /lib/libc.so.6 (0x2ac7c000)
        fix!.so => /lib/fix!.so (0x2ada8000)
        libg++.so.27 => /usr/lib/netscape/libg++.so.27 (0x2adec000)
        libstdc++.so.27 => /usr/lib/netscape/libstdc++.so.27 (0x2ae6b000)
        libm.so.6 => /lib/libm.so.6 (0x2aee9000)
        /lib/ld.so.1 => /lib/ld.so.1 (0x2aaab000)

This happens because this is netscape 4.05, which was built with
really old binutils, and so it starts at address 0x00200000 and
there's not much room below there.

-- 
Geoffrey Keating <geoffk@ozemail.com.au>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]