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

[Jack Carter <Jack dot Carter at imgtec dot com>]

I finally figured out the disconnect and it is me. 

I worked at SGI for a very long time. I worked on the linker and implemented
their multigot. SGI did different things with the GOT than GNU.

SGI would mark in the got regions for INTERNAL, HIDDEN and PROTECTED
entries and keep the symbol reference to them. I believe they stayed in the
.dynsym table, but kept their STO visibility markings. I could dump the got
and get symbolic information.

GNU doesn't do this. They say that internal, hidden and probably protected
are locals and just need the loadtime fixup value to make them right and thus
don't need to refer to any symbols.

Neither is wrong, just a bit different.

Thus for GNU, to fixup the ifunc entries in the local got I need to partition it from
the other local got entries and have explicit offsets to at least the old local got
region, the new ifunc local got region and maybe even the global got region in case
there are future got region shuffling and or additions.

Is there a preference for the ifunc local got to be before the regular local got or after?

If I got anything wrong please let me know.

And yes, I may be asking bfd questions as I implement the static linker. The dynamic 
linker should be straight forward.

Thanks for the patience and feedback,

Jack
________________________________________
From: Richard Sandiford [rdsandiford@googlemail.com]
Sent: Tuesday, December 10, 2013 1:22 AM
To: Jack Carter
Cc: Maciej W. Rozycki; binutils@sourceware.org; Doug Gilmore
Subject: Re: [Mips}Using DT tags for handling local ifuncs

Richard Sandiford <rdsandiford@googlemail.com> writes:
> Jack Carter <Jack.Carter@imgtec.com> writes:
>> Yes gdb needs to change a little, but that is not really the issue. The
>> gdb change is relatively small.
>>
>> The question is why do it if benefits in reality no one as I suspect
>> will be the case?
>> Where is the bang for the buck?
>>
>> That said, I am assuming I will have to do it and will make it work, but
>> I don't see why really.
>
> Experience suggests that if we take a short-cut here we'll regret it later.
> And it would be much harder to add something like this once ifuncs are
> already used in the wild.  The behaviour of the static linker would
> then depend on whether the dynamic linker supported the new tag and
> we'd effectively have two forms of ifunc ABI.  So if we go with the
> current approach we have to be as certain as we can be that we'll never
> want to revisit that decision.
>
> Are you pushing back because of the bfd implementation?  If you're
> hitting problems with that then please go into details.

BTW, I don't think this is just about DSOs vs. PIEs.  I think you'll
need it even for DSOs.  E.g. if a DSO contains:

  void foo1 (void) { printf ("foo1\n"); }
  void (*resolve_foo (void)) (void) { return foo1; }
  void foo (void) __attribute__ ((ifunc ("resolve_foo"),
                                  visibility ("hidden")));
  void (*get_foo (void)) (void) { return foo; }

then I think get_foo will need an IRELATIVE GOT entry for foo.  We can't
rely on an ifunc dynsym in this case.

Thanks,
Richard