Uma shankar <shankar.vk@xxxxxxxxx> writes: > On Wed, Oct 14, 2009 at 1:06 AM, Richard Sandiford > <rdsandiford@xxxxxxxxxxxxxx> 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
