Re: Damaged PPC_REL24 handling

[Daniel Jacobowitz <drow+@cs.cmu.edu>]

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.

Dan