This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]