* Description of MIPS/IRIX multigot
@ 2014-03-17 22:39 Jack Carter
2014-03-18 8:39 ` Richard Sandiford
0 siblings, 1 reply; 4+ messages in thread
From: Jack Carter @ 2014-03-17 22:39 UTC (permalink / raw)
To: binutils, libc-alpha; +Cc: rdsandiford, macro
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Description of MIPS/IRIX multigot
2014-03-17 22:39 Description of MIPS/IRIX multigot Jack Carter
@ 2014-03-18 8:39 ` Richard Sandiford
2014-03-18 17:54 ` Jack Carter
0 siblings, 1 reply; 4+ messages in thread
From: Richard Sandiford @ 2014-03-18 8:39 UTC (permalink / raw)
To: Jack Carter; +Cc: binutils, libc-alpha, macro
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: Description of MIPS/IRIX multigot
2014-03-18 8:39 ` Richard Sandiford
@ 2014-03-18 17:54 ` Jack Carter
2014-03-18 18:54 ` Maciej W. Rozycki
0 siblings, 1 reply; 4+ messages in thread
From: Jack Carter @ 2014-03-18 17:54 UTC (permalink / raw)
To: Richard Sandiford; +Cc: binutils, libc-alpha, macro
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-03-18 18:54 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-03-17 22:39 Description of MIPS/IRIX multigot Jack Carter
2014-03-18 8:39 ` Richard Sandiford
2014-03-18 17:54 ` Jack Carter
2014-03-18 18:54 ` Maciej W. Rozycki
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).