Description of MIPS/IRIX multigot

Description of MIPS/IRIX multigot

[Jack Carter]

I am retiring in a few days and I don't believe SGI/MIPS ever published 
the IRIX multigot description. My work with the current GCC/MIPS 
multigot solution has strengthened my opinion that IRIX had it right. 
Probably because I am a linker guy and had to suffer with debugging 
multigot issues with a lot of big iron applications and dsos ;-)

In the MIPS/IRIX point of view the GOT (GlobalOffsetTable) only held 
elements that were symbol related. Data for other GP relative elements 
remained in their own sections. A GP region would span 64K bytes of 
memory. GP relative sections are so marked with SHF_GPREL. Example of 
such sections are:

* .got
* .sbss
* .sdata
* .lit4
* .lit8

If there were more GP relative section data than could fit in one 64K region, Multiple GP regions were created.

Each GP region had its own dynamic section describing elements that the 
dynamic linker needed to know. The initial dynamic section had all the 
standard dynamic tags such as :

* DT_NEEDED
* DT_RELA
* DT_RELSZ
* etc.

It also had one or more DT_MIPS_AUX_DYNAMIC tags pointing to the 
"auxiliary dynamic sections describing the other GP regions. These 
dynamic sections had the following records:

* DT_MIPS_GP_VALUE: 
  The GP value for this GP region
* DT_MIPS_HIPAGENO: 
  This member contains the number of page table entries 
  in the GOT. It is used by profiling tools and is optional.
* DT_MIPS_LOCAL_GOTNO: 
  Number of local GOT entries
* DT_MIPS_LOCALPAGE_GOTIDX:
  Index of first page table entry for a segment.There will be one per 
  segment, in the same order as the segments in the segment table. They 
  are mandatory if there are page table entries for any segment, and the 
  value for a segment without any page table entries must be zero.
* DT_MIPS_LOCAL_GOTIDX:
  This member contains the index in the GOT of the first entry for a 
  local symbol. It is mandatory if there are local symbol entries.
* DT_MIPS_HIDDEN_GOTIDX: 
  This member contains the index in the GOT of the first entry for a 
  hidden symbol. It is mandatory if there are hidden symbol entries.
* DT_MIPS_PROTECTED_GOTIDX:
  This member contains the index in the GOT of the first entry for a 
  protected symbol. It is mandatory if there are protected symbol entries.

The first dynamic section, the one pointed to by PT_DYNAMIC, behaves 
closely as we currently know and love with implicit dynamic link time 
relocation. The auxiliary dynamic sections listed in the initial dynamic
 section, have only explicit relocations with the exception of the local
 page entries. Those entries are implicitly relocated by adding the dso 
load offset if any. I wouldn't be surprised if all the "local" entries 
were not implicitly relocated, but that limits what kind of relocations 
one wants to apply.

Both the initial and auxiliary dynamic sections have the auxiliary tags. 
That is, the initial dynamic section has DT_MIPS_GP_VALUE,
DT_MIPS_LOCAL_GOTNO, etc..

We had the convention of ordering the GOT regions as:

1 Reserved words
2 Page offsetsLocals:  Regular locals symbol as well as STV_INTERNAL symbols.
3 Hidden: These are not local since they can be passed by address.
4 Protected
5 Global

I'm sure we would at this time have added TLS

Why do it this way? Transparency and debugging.

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

* The GOT is just another section in a GP
  region. When you dump the section headers you will see the other 
  sections associated with this GP one after the other, not hidden within 
  the confines of .got. Since we always started with the dynamic section 
  in the GP region, my pretty printer could display the different groups 
  of sections per GP region aided by the SHF_GPREL flag value.

* Debugging. Maybe only a handful of people in the world care about debugging 
  multigot issues, but it is a major boost to be able to dump with the 
  pretty printer the detailed contents of each of the GOTs and to see the 
  full picture. When I dumped a multigot object with my pretty printer I 
  saw each of the GP values for each GP region and the contents of each of
  the GOTs by category.

One thing I believe we lacked was the count or end of each of the GOT partitions.
We had it for some like HIPAGENO, but not all. This is needed if you wanted to 
add a new partition and the heuristic of where HIDDEN ended was not just Where 
PROTECTED began.

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

Anyway, It is now out in public in case anyone else wants to ever adopt it for MIPS :-)

Cheers,

Jack

Re: Description of MIPS/IRIX multigot

[Richard Sandiford]

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

RE: Description of MIPS/IRIX multigot

[Jack Carter]

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

RE: Description of MIPS/IRIX multigot

[Maciej W. Rozycki]

Jack,

> Just one shot before fading in the sunset ;-)

 Thanks for the write-up and for your contribution to the development of 
the MIPS architecture over the years.  Enjoy your retirement, good luck!

  Maciej