Re: [Mips}Using DT tags for handling local ifuncs

[Richard Sandiford <rdsandiford at googlemail dot com>]

Jack Carter <Jack.Carter@imgtec.com> writes:
> Through my eyes having a commandline option to reduce the GP area is
> essential to testing. It doesn't take away from testing the legal
> limits which is crucial, but it really pushes the code with smaller
> easier to read bits. And yes, using .rept will help me :-)

OK, I think this is something that needs to have a motivating test
to justify it.  I.e. a test that couldn't be done elegantly or easily
using the real limit.

> I also have a hard time with how the GOT is used for binutils. In my
> experience and world view, sections have attributes that make them gp
> relative or not. All these sections get gathered in gp relative
> regions that are 64k from a value that will be in their $GP. If there
> are GOT elements that are not gp relative, they should be in another
> .got that is not marked SHF_MIPS_GPREL. It will not get laid out and
> calibrated with any of the other GOTs.  Other sections in my life that
> get bundled up in the equation for multigot are .sbss, .sdata,
> .lit[4,8,16], .srdata, but only if they are marked SHF_MIPS_GPREL.

Just so I understand, do you think that the ABI GOT should always be 64k
or smaller?  I.e. DT_MIPS_LOCAL_GOTNO + (DT_MIPS_SYMTABNO - DT_MIPS_GOTSYM)
should be <= 64 * 1024 / sizeof (void *)?  If so, what should happen
(under the original or IRIX n32/n64 ABIs) if the number of symbols
involved in .rel.dyn relocations exceeds the 64k limit?  Is that a
link error?

> The DT_MIPS_LOCAL_GOTNO describes local got entries. Not other
> partitions that we reserve the right to put non-local got entries.

I'm still not sure which part you're describing as the local GOT here.
Let's go back to the original 32-bit GOT layout, without any GNU extensions:

      +------------+   +    <--- DT_PLTGOT
      |   entry 0  |   |
      +------------+ + B
      |  ........  | A |
      +------------+ + +    <--- DT_PLTGOT + DT_MIPS_LOCAL_GOTNO * 4
      | Global GOT |      
      +------------+

where:

  The zero entry in the global offset table is reserved to hold the
  address of the entry point in the dynamic linker to call when lazy
  resolving text symbols. The dynamic linker must always initialize this
  entry regardless of whether lazy binding is or is not enabled.

Do you see the local GOT as being A or B?  I.e. does it include
the zero entry?

> You are correct, if we applied the implicit R_MIPS_IRELATIVE as
> opposed to the the stated it would go against the stated "
> R_MIPS_REL32 relocation type is the only relocation performed by the
> dynamic linker".

FWIW I wasn't arguing that.

> Dealing with the ifunc "local" entries implicitly will save a
> relocation lookup, a tiny blip of time in relation to the other costs
> of calling the resolver. So I am arguing about how many angels can
> dance on a pin.

Yeah, maybe this is one we'll have to agree to disagree on.  I think the
benefit of having an implicitly-relocated irelative region is small at best.
I like the generality of including the GOT R_MIPS_IRELATIVE GOT
relocations in the general .rel.dyn pool and sorting them accordingly,
because it feels more future-proof.  I also think an implicit region is
harder to handle in a backward-compatible way, since if we just add new
tags, older ld.sos would ignore them and not flag an error.

If someone else has any opinions about implicit irelative relocs vs.
explicit irelative relocs though, please shout.

Thanks,
Richard