This is the mail archive of the
mailing list for the binutils project.
Re: [Mips}Using DT tags for handling local ifuncs
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: "Maciej W. Rozycki" <macro at codesourcery dot com>
- Cc: Jack Carter <Jack dot Carter at imgtec dot com>, "binutils\ at sourceware dot org" <binutils at sourceware dot org>, Doug Gilmore <Doug dot Gilmore at imgtec dot com>
- Date: Sat, 14 Dec 2013 10:06:33 +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> <4CEFBC1BE64A8048869F799EF2D2EEEE4C6DE23E at BADAG02 dot ba dot imgtec dot org> <87txef6a07 dot fsf at talisman dot default> <4CEFBC1BE64A8048869F799EF2D2EEEE4C6DE3B8 at BADAG02 dot ba dot imgtec dot org> <87haaf5hbg dot fsf at talisman dot default> <4CEFBC1BE64A8048869F799EF2D2EEEE4C6DE50C at BADAG02 dot ba dot imgtec dot org> <877gbb5c2k dot fsf at talisman dot default> <4CEFBC1BE64A8048869F799EF2D2EEEE4C6DE59A at BADAG02 dot ba dot imgtec dot org> <alpine dot DEB dot 1 dot 10 dot 1312112311480 dot 19368 at tp dot orcam dot me dot uk> <87y53q4czx dot fsf at talisman dot default> <alpine dot DEB dot 1 dot 10 dot 1312121406040 dot 19368 at tp dot orcam dot me dot uk> <87ppp14wr7 dot fsf at talisman dot default> <alpine dot DEB dot 1 dot 10 dot 1312131400280 dot 19368 at tp dot orcam dot me dot uk>
"Maciej W. Rozycki" <email@example.com> writes:
> On Thu, 12 Dec 2013, Richard Sandiford wrote:
>> > Hmm, thanks for reminding me that, that rules out the space before the
>> > ABI GOT. We still have space afterwards for things like this (or e.g. for
>> > a small-data area if we ever implement it) though.
>> Yeah, putting it afterwards is what we already do for TLS relocs.
>> The problem with that is that the ABI global GOT has to include all
>> symbols that have a relocation against them, even if there's no need
>> for a $gp-relative GOT access. And there can be quite a lot of symbols
>> like that, especially for things like vtables in C++ code.
>> So if we put the relocations after the ABI GOT we would end up forcing
>> the use of multigots even though the number of "real" GOT entries
>> (those that need to be accessed $gp-relative) is small enough for
>> a single GOT. The idea of the tag is to avoid that.
> I see, that makes sense to me. Do we already care to sort GOT entries
Yeah, this is GGA_NORMAL vs. GGA_RELOC_ONLY in elfxx-mips.cs
> Also let's make sure old ld.so binaries fail in a sensible way with ifunc
> binaries though, i.e. no segfault or suchlike.
I agree it's worth checking, but in this case it should do, because we'll
only be using the new area for R_MIPS_IRELATIVE, which is a new relocation
type. ld.so does complain about types it doesn't understand.
>> > Fair enough, but then, after a bit of thinking, do we need
>> > %highest/%higher stuff in the first place? For n64 non-PIC PLT is only
>> > supported for msym32 binaries anyway and it doesn't look to me it is ever
>> > going to change, so the high 33 address bits will always be zero and the
>> > 32-bit version (with LD rather than LW) will do, and for SVR4 PIC binaries
>> > you need to figure out the GOT pointer from $t9 instead (is there any
>> > point in making a difference between ET_EXEC and ET_DYN binaries here?);
>> > note that this would exclude ifunc calls from being tail calls (breaking
>> > the standard calling convention) so it looks to me we'll have to make an
>> > extra stub to load $gp beforehand.
>> > Have I missed anything?
>> One of the main reasons for requiring -msym32 for PLTs is that absolute
>> code is only really interesting if you can use %hi and %lo to access symbols.
>> If you need the full %highest/... sequence then it's often better to use
>> a GOT instead.
>> But despite the name, IPLTs are different. They are used regardless of
>> whether the input is new-style absolute code or SVR4 PIC. ifuncs in
>> themselves shouldn't force -msym32.
> Of course they shouldn't *force* -msym32 -- what I mean is the absolute
> sequence is only applicable for PLT executables, that imply one of -32,
> -n32 or -msym32 already. For shared libraries an absolute sequence is
> useless as they're relocated at the load time so only offsets from PC (or
> GP, once that's been figured out) can be used. So we'd have to come with
> a different sequence anyway.
> For executables using traditional SVR4 PIC code we could use the absolute
> sequence indeed. However I checked the ifunc ABI description again and no
> lazy binding is proposed for ifuncs so no stub of any kind will be
> required for PIC code (be it an executables or a shared library) as all
> calls are made through the GOT there anyway and this will have been
> relocated by the time any ifunc call is reached.
OK, once we start using the new GOT region then I agree we can make
that the case. In terms of the ABI and patch as posted though, we used
IPLTs for all ifuncs defined in executables:
Dynamically linked executables with ifunc definitions are for the most
part the same as static executables, with the following exceptions:
*) No __rel_iplt_start/end symbols. The dynamic linker handles dynamic
*) Generate STT_GNU_IFUNC symbols in the .dynsym section with the value
being the iplt entry for this IFUNC and transform them into
STT_FUNC symbols. Any references to this IFUNC have to go through
the stub. The dynamic linker (ld.so) will be doing the fixup at start-