Description of MIPS/IRIX multigot
Jack Carter
Jack.Carter@imgtec.com
Mon Mar 17 22:39:00 GMT 2014
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
More information about the Libc-alpha
mailing list