Re: Damaged PPC_REL24 handling

[Geoff Keating <geoffk@ozemail.com.au>]

> Cc: Geoff Keating <geoffk@ozemail.com.au>, libc-alpha@gnu.org
> Reply-To: drepper@cygnus.com (Ulrich Drepper)
> From: Ulrich Drepper <drepper@cygnus.com>
> Date: 13 Nov 1998 15:36:39 -0800
> 
> Daniel Jacobowitz <drow+@cs.cmu.edu> writes:
> 
> > Something is wrong with the handling of R_PPC_REL24 relocations.  This
> > error keeps getting triggered:
> > 
> >     case R_PPC_REL24:
> >       {
> >         Elf32_Sword delta = finaladdr - (Elf32_Word) (char *) reloc_addr;
> >         if (delta << 6 >> 6 != delta)
> 
> Try replacing this with
> 
> 	  if (delta & ~0x3fffffc)

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.

>    Dan forgot to mention that the program which routinely displays this
> behavior under linuxppc is mozilla.

Hmmm.  It wouldn't happen to be larger than 32M (or whatever) in size,
would it?  There's an upper limit on the size of executables around
there (within a factor of 2) on ppc, which is tricky to work around in
ld.

> delta == 0xd112db70
> finaladdr == 0x017a2664
> reloc_addr == 0x30674af4

What does ldd report?

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


In future bug reports, can you please specify:

- binutils version
- gcc version
- glibc version
- kernel version
- the precise symbol(s) involved in the problem, as reported by
  objdump -T
- the reloc(s) involved, as reported by objdump -R
- the result of running ldd on whatever executable is being used

and any other information you think may be helpful.

It is _really important_ to specify the first four every time, as
all these are under active development.

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