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

[Richard Sandiford <rdsandiford at googlemail dot com>]

Jack Carter <Jack.Carter@imgtec.com> writes:
> Richard,
>
> I started to implement the suggestion of using dynamic tags to process
> ifunc entries in the GOT table. The more I worked on it the more it
> concerns me. Not that it wouldn't facilitate the GOT fixups to avoid
> having to go through the iplt stubs, but the danger introduced for so
> little real use.
>
> It would only benefit calls from within a pic executable to ifunc
> routines defined within the pic executable. It would not benefit
> non-pic calls, static link calls, calls from dsos to the pic
> executable.
>
> We invision almost exclusive use from ifunc routines defined in
> dsos. There is not iplt stub use in that case. And in the case of
> statically (non-shared) linked executables, I don't see any way around
> iplt stubs.
>
> The MIPS GOT layout assumes that local gots start at DT_PLTGOT and
> that the global GOT area starts at the end of the local GOT area. What
> we have the number of local GOT entries and number of global GOT
> entries. A lot of tools work on this assumption. The static linker is
> hard coded to work on this assumption

Right, but of course the idea was to change the static and dynamic linker.
We're doing that anyway to support ifuncs -- it's not like either tool
handles them now.

I suppose it just doesn't seem that big a step to me.  Although the GOT
starts at the DT_PLTGOT, the start of the local area is derived indirectly.
It started at entry 1 in the original psABI but starts at 2 with GNU
extensions.  A bit is set in entry 1 to say whether the GNU extension
is in use.  All I'm saying is that we should have an optional tag to
specify the start explicitly.  It would then be possible to handle
entries 2 to N using normal relocations.

In glibc we do:

  got = (ElfW(Addr) *) D_PTR (map, l_info[DT_PLTGOT]);			\
									\
  if (__builtin_expect (map->l_addr == 0, 1))				\
    break;								\
									\
  /* got[0] is reserved. got[1] is also reserved for the dynamic object	\
     generated by gnu ld. Skip these reserved entries from		\
     relocation.  */							\
  i = (got[1] & ELF_MIPS_GNU_GOT1_MASK)? 2 : 1;				\

I'm just suggesting that we change the last line to:

  i = map->l_info[DT_MIPS (NEW_TAG)]->d_un.d_val;			\
  if (i == 0)								\
    /* got[0] is reserved. got[1] is also reserved for the dynamic	\
       object generated by gnu ld. Skip these reserved entries from	\
       relocation.  */							\
    i = (got[1] & ELF_MIPS_GNU_GOT1_MASK) ? 2 : 1;			\

and similarly in RESOLVE_GOTSYM.

> This is not to say that it cannot be done, but is it worth the bang
> for the buck? How many debuggers, simulators, object dumpers am I
> going to mess up making a change that few will benefit from?

Debuggers shouldn't care.  At least I don't think GDB does.

But the point is that if we don't need irelative relocations in the GOT
then the layout doesn't change.  The local GOT still starts at entry 2
and tools that work that out from entry 1 rather than the new tag will
continue to work.  And if ifuncs are used, the simulators and object
dumpers would need to be extended to work with those anyway.

Thanks,
Richard