This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Description of MIPS/IRIX multigot

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]