This is the mail archive of the
mailing list for the glibc project.
Re: [RFC] Add IFUNC support for MIPS (v3)
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Faraz Shahbazker <faraz dot shahbazker at imgtec dot com>
- Cc: "libc-alpha\ at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Mon, 17 Aug 2015 21:01:24 +0100
- Subject: Re: [RFC] Add IFUNC support for MIPS (v3)
- Authentication-results: sourceware.org; auth=none
- References: <DCB1C42372B1674B8F912A294CCB775A71684631 at BADAG02 dot ba dot imgtec dot org> <87k2tdn5xt dot fsf at googlemail dot com> <55BFC10F dot 2050503 at imgtec dot com> <87k2tapwq0 dot fsf at googlemail dot com> <55CE5217 dot 5020902 at imgtec dot com> <87io8f2gc9 dot fsf at googlemail dot com> <55D23368 dot 1070705 at imgtec dot com>
Faraz Shahbazker <email@example.com> writes:
> On 08/16/2015 12:17 PM, Richard Sandiford wrote:
>> We should probably report an error in cases where we see a global symbol
>> and the tag isn't defined, rather than silently mislink the code.
> A REL32 reloc with an IFUNC symbol could very well be for a data section.
> Though its safe to assume that there would be a corresponding relocation for
> the explicit GOT region as well, we wouldn't know which is which trivially,
> from inspecting the relocation. Wouldn't it look confusing if we check for the
> presence of GENERAL_GOTNO even for relocations that don't modify the general
> GOT region?
I was thinking that we should always have the DT_MIPS_GENERAL_GOTNO
if the DSO has a relocation against an ifunc. There's no requirement
for DT_MIPS_GENERAL_GOTNO to be greater than 2 (i.e. for the new GOT
region to be nonempty).
The tag is really saying two things: there's a new region in the GOT
(possibly empty) and global symbols that feature in relocations no
longer need to be in the DT_MIPS_GOTSYM region. The second is really
a prerequisite for the first.
Personally I wouldn't mind relaxing the DT_MIPS_GOTSYM rule unconditionally.
I just got the impression that others preferred the tools to reject objects
that don't follow the old ABI and don't explicitly request a new ABI feature.