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]

Description of MIPS/IRIX multigot

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 :

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

  The GP value for this GP region
  This member contains the number of page table entries 
  in the GOT. It is used by profiling tools and is optional.
  Number of local GOT entries
  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.
  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.
  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.
  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,

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 

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 :-)



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