Description of MIPS/IRIX multigot

Jack Carter Jack.Carter@imgtec.com
Tue Mar 18 17:54:00 GMT 2014


Richard, I genuinely enjoyed working with you.

Just one shot before fading in the sunset ;-)

Almost all the IRIX multigot differences are in giving an organized structure to describing the got layout(s). It doesn't change much of what needs to be done within. This is a philosophical view of how to add functionality. Always be explicit in the ELF structures for describing what is there. Be orthogonal in how you do it.

The gnu linker would behave much the same way, creating faux GOTs for each of the input objects and adding them, along with the other gp relative sections within the input object to the current aggregate gp region.

There wouldn't be a "master" GOT that included all GOT entries. Just an initial GOT that would follow the dynamic symbol table order matching convention for global symbols followed by other gp regions each with a GOT that uses exclusively relocations for non-page table entries. Each GP region represents a 64 K byte range max.

Doesn't matter any more. My bees and chickens aren't interested in multigot even though I have tried to go over it with them on numerous occasions. And my wife still wonders after all these years why I keep talking about elfs, dwarfs and pixies.

Cheers,

Jack

________________________________________
From: Richard Sandiford [rdsandiford@googlemail.com]
Sent: Tuesday, March 18, 2014 1:38 AM
To: Jack Carter
Cc: binutils@sourceware.org; libc-alpha@sourceware.org; macro@codesourcery.com
Subject: Re: Description of MIPS/IRIX multigot

Jack Carter <Jack.Carter@imgtec.com> writes:
> I am retiring in a few days

Congratulations!  All the best for your retirement.  And thanks for
the write-up.

> * It follows the ELF philosophy of packaging data in an orderly fashion. The
>   different elements of the GOT are no longer just LOCAL and GLOBAL.
>   Visibility like Protected, hidden and global are separated and
>   specifically pointed to. This helped post linkage instrumentation tools
>   like pixie do the right thing.

I don't buy this though.  Visibility information is already given by the
symbol table.  There's no need to duplicate it in the GOT tags.

> Yes I know, you can get it working without all of the above
> information, but why make a tough job tougher?

Heh, well, I know I'm going over old ground, but this sounds like it
_is_ making a tough job tougher :-)  We already support the same thing
(bar lazy binding in secondary GOTs) for GNU/Linux, in a much simpler
way and without having had to extend the ABI, or surprise generic ELF
readers by having several .dynamic sections.

The way that the original psABI tied global symbols to the GOT was a
nice trick for saving space and providing a free cache, but when it
comes to secondary GOTs, the advantage seems the other way: having
a relocation per GOT entry is simpler, more safe-efficient and quicker
at load time than adding extra .dynamic sections and duplicating part of
the symbol table.  The missing feature of lazy binding in secondary GOTs
could be handled by relocations too; the net effect would still be
simpler than having several .dynamics.

So IMO, while the psABI got it right by having an efficient way of
handling simple local and global entries, other targets got it right
by allowing the GOT to be just a bunch of data that can be relocated
like any other.  This includes relocs that weren't envisaged at the time,
like TLS and ifunc.

So I think the guys who added MIPS TLS made the right call by having the
TLS GOT entries be relocated normally.  And I think it's the right call
for ifunc too.

I still think it would be good to allow these normally-relocated entries
in the main part of the GOT though, rather than having to tack them on
after all the ABI-mandated global GOT entries (including those that are
needed only because there's a relocation against a particular global
symbol).  As we discussed before, all that needs is a new tag.

Thanks,
Richard



More information about the Binutils mailing list