This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: RFC: using ld 2.14 on irix
Thanks for the feedback!
Alexandre Oliva <aoliva@redhat.com> writes:
> > So the three dynamic relocations will be calculated as:
>
> > A - EA + S
>
> > where A = addend (0 in all three cases)
> > EA = contents of GOT
> > S = final symbol value
>
> > Since libc.so.1 is loaded at its QuickStart address, EA = S,
> > and all three variables stay as 0.
>
> Eeeek. This is what I feared. You seem to be saying that the linker
> is actually required to take addresses from the shared object you link
> with and place them in the newly-linked file, and then, if it turns
> out that you use a different shared object, this incorrect address
> will somehow cancel out and things will work.
Well, yes and no. What you describe seems to be the quickstart works.
I.e. if object A references shared object B, A is set up with the
symbol values that ld saw when reading B. Both the GOT and data
section contain these addresses. So A = EA, A - EA = 0 and the
relocation field will always be set to S.
But I think the correct thing for non-quickstart objects is to set
both the GOT entry and data section contents to zero. Then A = 0
and EA = 0, so again the relocation field will always be set to S.
> > With these changes I was able to successfully bootstrap gcc 3.4
> > using GNU as & ld.
>
> I didn't have much trouble Bootstrapping GCC on Irix 6 before the mips
> rewrite, using GNU as and ld.
Yeah, I guess I should come clean here ;). In the bootstrap failure
I saw, gcc was needlessly forcing constants into memory. It was
these constants that were not being relocated properly. I plan to
fix the gcc side soon...
For the record (and I realise you weren't blaming this on gcc ;)
the same sort of thing could happen before mips rewrite. Global
symbols + large constants would sometimes be forced into memory.
Richard