This is the mail archive of the
mailing list for the binutils project.
Re: Multigot mechanism and a related MIPS linker error
- From: Uma shankar <shankar dot vk at gmail dot com>
- To: binutils at sourceware dot org, gcc-help at gcc dot gnu dot org, rdsandiford at googlemail dot com
- Date: Tue, 10 Nov 2009 23:55:01 +0530
- Subject: Re: Multigot mechanism and a related MIPS linker error
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
On Tue, Nov 10, 2009 at 1:29 AM, Richard Sandiford
> I'm not sure I understand the question, sorry.
>> I do not understand how the functions inside a.o, b.o and c.o can
>> access the common symbols ?without ?duplicating those
>> symbols in primary and secondary GOTs . ( I did look at ?.rel section
>> of an ?exe and ?did find multiple
>> entries for some common symbols like printf )
> Exactly. ?That's the point I was trying to make. ?We sometimes need to
> duplicate symbols in order to keep everything within range of a 16-bit
> load offset. ?And the problem is that the ABI-defined, reloc-free GOT
> scheme you were asking about only allows a symbol to be mentioned once.
> We therefore add secondary GOTs that are (from an ABI point of view)
> just "blobs of data" that are relocated by R_MIPS_REL. ?Those blobs of
> data all refer to symbols in the ABI-defined GOT, since every symbol
> mentioned in a relocation must also be in the ABI-defined GOT.
> In other words, every entry in a secondary GOT duplicates a symbol
> in the ABI-defined GOT.
>> Also, how is the best multigot layout found - the one with least
>> duplicated entries ?
> We don't work too hard on that. ?It's an NP-complete problem.
> We just go through each input object in turn and try the following
> three things, in order:
> ?- use the primary GOT
> ?- use the last-used secondary GOT
> ?- create a new secondary GOT
> (This algorithm is from memory, so sorry if I'm oversimplifying.)
I have a bit of understanding now.
I guess i will have to figure out the rest by some analysis and
searching the mailing lists for information .
The linker code itself will take much more time to understand.
There is no other source of information on MIPS linker internals, I suppose.
[ As I mentioned in the first post, my official task is to create
some obj files and try to link them into a shared-library This
linking should fail due to the reasons that are addressed by the
patch posted at
And later, with the patched loader, it should link.
So, I have to understand what data and function accesses should be
present in the objs for that problem to occur.
I won't ask for it ; but I won't mind getting some clue from you. =;) ]