Re: Multigot mechanism and a related MIPS linker error

[Richard Sandiford <rdsandiford at googlemail dot com>]

Uma shankar <shankar.vk@gmail.com> writes:
> On Wed, Oct 14, 2009 at 1:06 AM, Richard Sandiford
> <rdsandiford@googlemail.com> wrote:
>> The primary GOT lives at the start of the ABI-defined GOT, and is
>> managed in the usual relocation-free way. ÂThe secondary GOTs are
>> instead just blobs of data that are relocated in the same way as
>> ordinary data, using the R_MIPS_REL32s that you saw.
>>
>> Of course, every global symbol involved in a relocation must also
>> be in the ABI-defined GOT, so that GOT is often bigger than 64k.
>> However, the primary GOT lives at the beginning of the ABI-defined
>> GOT and is always <64k in size.
>>
>> We could try to optimise the case where input objects (or groups
>> of input objects) have GOTs that don't overlap at all, but that's
>> so rare that I don't think it's worth bothering in practice.
>>
>> Richard
>>
>>
>
> Thanks for the reply.
> What qualifies a  symbol to be put in primary GOT ?  Is this just  on
> "as seen" basis during linking ?
>
> Suppose i am linking  3 files  a.o , b.o  and c.o  into  a
> dynamically-linked executable.
> Also,  assume that  each of these 3 files  access 16 K globals ( local
> + extern ). Out of this, let
> 4K be  common symbols , such as  from libc.
>
> The simple way of creating GOT of the exe will be to put  entries for
> all globals of a.o  in primary GOT .
> And the entries for b.o and c.o  will be "blobs of data" you mention -
> to be relocated dynamically.
>
> But I assume  it will not be done this way.  The common symbols  may
> get a preferential place in primary GOT. If so,
> I  have not understood the reason.

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