Re: RFC: using ld 2.14 on irix

[Alexandre Oliva <aoliva at redhat dot com>]

On Jun 14, 2003, Richard Sandiford <rsandifo@redhat.com> wrote:

> (cheesily borrowing symbols from libc.so)

You don't have to go that far.  Just set a global pointer to say the
address of function exit.

> In the object created by ld 2.14, f1, f2 and f3 are initialised to 0:

>     Contents of section .data:
>      1010061c 00000000 00000000 00000000           ............    

This feels like the only sane behavior to me for external symbols.
Anything else requires peeking into a shared object that may be
different from the one actually used at run-time.

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

> I have no idea what effect this would have on backwards compatibility.

It's not like we have a lot of N32/N64 history to be compatible with.
Alternatively, we could retain the current behavior for GNU/Linux and
follow Irix's...  erhm... features?...  when linking for Irix.

> 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.  I had problems building other tools,
such as makeinfo and expect (IIRC), that had global pointers to libc
functions and therefore ran into this problem.

> Anyway, what do you think?  Am I just talking rubbish here? ;)

Not at all.  You seem to have figured out at least parts of this
puzzle.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer