Re: Multigot mechanism and a related MIPS linker error

[Uma shankar <shankar dot vk at gmail dot com>]

On Tue, Nov 10, 2009 at 1:29 AM, Richard Sandiford
<rdsandiford@googlemail.com> wrote:
>
> 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.)
>
> Richard
>
ok.
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
http://sourceware.org/ml/binutils/2008-06/msg00270.html .
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.   =;)  ]

               thanks
               shankar