This is the mail archive of the
libc-alpha@cygnus.com
mailing list for the glibc project.
Re: Damaged PPC_REL24 handling
On Sat, Nov 14, 1998 at 09:51:45AM +0100, Philip Blundell wrote:
> >The numbers for my problem case (this appeared while building mozilla;
> >I've also seen it with an 800K .so generated by mod_perl):
> >
> >delta == 0xd112db70
> >finaladdr == 0x017a2664
> >reloc_addr == 0x30674af4
> >
> >Because it is being relocated downwards, finaladdr - relocaddr is
> >negative; a negative delta, signed or not, certainly has its high bit
> >set.
>
> >From those numbers it looks to me like everything is working correctly and the
> address offset really is out of range. You're right that a negative delta has
> its top bit set but that shouldn't be a problem here.
>
> Try running this program and watch the results. You might like to remember
> that 0xffffffff is a valid offset for a 24-bit reloc (-1) but 0xefffffff is
> not.
Yes, that's more or less the conclusion I'd come to. Interestingly, by
adding a bunch of debugging statements - and only a bunch of debugging
statements, I checked very carefully - I have made this trigger
significantly more often, to the point where most c++ programs fail.
A little further investigation reveals this:
symbol name:
ic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b1i0Uic
loadbase sym->st_value reloc->r_addend
0178e000 00000000 00014664
And a random successfully loading symbol:
name: string_char_traits1ZcZt24__default_alloc_template2b1i0
loadbase sym->st_value reloc->r_addend
3075a000 00000000 00058004
Well, right off I recognize mangled names (although c++filt only
successfully unmangles about half of them, they're all in libstdc++).
And I recognize that that loadbase is seriously broken.
Could someone with a little more practice at this than I perhaps give
me a few hints for determining whether binutil's binary creation or
glibc's loading is at fault?
Dan