This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
RE: [Mips}Using DT tags for handling local ifuncs
- From: Jack Carter <Jack dot Carter at imgtec dot com>
- To: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: "Maciej W. Rozycki" <macro at codesourcery dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>, Doug Gilmore <Doug dot Gilmore at imgtec dot com>
- Date: Wed, 11 Dec 2013 00:20:21 +0000
- Subject: RE: [Mips}Using DT tags for handling local ifuncs
- Authentication-results: sourceware.org; auth=none
- References: <4CEFBC1BE64A8048869F799EF2D2EEEE4C6DDC0F at BADAG02 dot ba dot imgtec dot org> <87r49p9dit dot fsf at talisman dot default> <alpine dot DEB dot 1 dot 10 dot 1312092333190 dot 19368 at tp dot orcam dot me dot uk> <4CEFBC1BE64A8048869F799EF2D2EEEE4C6DDFC3 at BADAG02 dot ba dot imgtec dot org> <87ob4p6qdt dot fsf at talisman dot default>,<87k3fd6owc dot fsf at talisman dot default>
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