Re: use of gnu hash for MIPS

[Richard Sandiford <richard at codesourcery dot com>]

Sorry for the late reply.

Hiroki Kaminaga <kaminaga@sm.sony.co.jp> writes:
> 1) make .gnu.dynsym section
>    - which is specific for .gnu.hash, but obiously redundant
> 2) allow bitmap portion of gnu hash for MIPS
>    - to benefit speedup of that part (which is not bad idea, I think)
>    - the symbol lookup part is same as before

I admit I haven't really looked into this in enough detail to know
which of these alternatives (or other variations on the format)
would be better.  But...

> 3) Somehow work out to co-existance of sorting order of .dynsym
>
> Regarding choice 3), my understanding is as follows:
>
> .got requires order of
>
>   +------------+
>   | local sym  |
>   | local sym  |
>   +------------+  <- DT_MIPS_LOCAL_GOTNO
>   | extern sym |
>   | extern sym |
>   | extern sym |
>   +------------+
>
> but there is no constraints in ordering. (except to be 1:1 with
> .dynsym) On the other hand, gnu hash sorts .dynsym in hash value
> order. So, does this method work?
>
> 1) locate local symbols on first part
>    - to obey .got requirement
> 2) locate external sorted by hash after local symbols
>    - to apply gnu hash
> 3) sort .got entries according to hash value
>    - to obey .got 1:1 with .dynsym

I think this would interact badly with the multigot feature.  Symbols
in the primary GOT must come before those that aren't in the primary GOT,
so there's really a third division:

   +------------------------+
   | local sym              |
   | ...                    |
   | local sym              |
   +------------------------+  <- DT_MIPS_LOCAL_GOTNO
   | primary extern sym     |
   | ...                    |
   | primary extern sym     |
   +------------------------+
   | non-primary extern sym |
   | ...                    |
   | non-primary extern sym |
   +------------------------+

Secondary GOTs have an impact on start-up time too.  They disable
lazy binding and they rely on normal relocation entries instead of
the dynsym<->got mapping, thus increasing the number of symbol lookups
needed.  So I think the interests of the primary GOT take precedent
here; we don't want to make less use of it.

FWIW, I don't see any problem off-hand with sorting within these
three groups.  Page 5-14 of the psABI says:

  To take advantage of Quickstart functionality, the .dynsym and
  .rel.dyn sections must obey ordering constraints. The GOT-mapped
  portion of the .dynsym section must be ordered on increasing values in
  the st_value field. This requires that the .got section have the same
  order, since it must correspond to the .dynsym section.

but AIUI, the GNU tools have taken this to mean "if you're not using
QuickStart, don't bother", and symbols aren't ordered by increasing
st_value.

For extra flexibility, you might like to have an unbounded list
of external symbol blocks, each of which is sorted as required by
.gnu.hash.  Although I think we only need at most two blocks at
the moment, who knows what we'll need in future?

Richard