This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
RE: [RFC 2/2] Update prototype of IFUNC resolver for MIPS
- From: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- To: Joseph Myers <joseph at codesourcery dot com>, Faraz Shahbazker <Faraz dot Shahbazker at imgtec dot com>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, Robert Suchanek <Robert dot Suchanek at imgtec dot com>
- Date: Mon, 14 Sep 2015 14:25:34 +0000
- Subject: RE: [RFC 2/2] Update prototype of IFUNC resolver for MIPS
- 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> <87io8dhegb dot fsf at googlemail dot com> <55D269D2 dot 2030208 at imgtec dot com> <87si7h6oyv dot fsf at googlemail dot com> <55D7A3C5 dot 8050600 at imgtec dot com> <87vbc7u1df dot fsf at googlemail dot com> <55E8C3C5 dot 8000107 at imgtec dot com> <alpine dot DEB dot 2 dot 10 dot 1509032210000 dot 24787 at digraph dot polyomino dot org dot uk>
Joseph Myers <joseph@codesourcery.com> writes:
> On Thu, 3 Sep 2015, Faraz Shahbazker wrote:
>
> > Comments are invited on the prototype of the IFUNC resolver for MIPS.
> > We want something flexible enough to handle current requirements and
> extensions.
> >
> > This patch, from RobertS, provides the resolver with 2 HWCAP registers
> > and a callback control function. The callback currently provides the
> > ability to toggle/switch between FP ABI modes.
>
> Please give a much more detailed explanation of the background to and
> motivation for this patch - why you need something that doesn't appear
> to be present for any other architecture.
I don't think there is much to debate over whether MIPS ifunc resolvers
take the hwcaps as arguments. That is common with other architectures
and it seems sensible to pass hwcap and hwcap2 for MIPS given we have
such wide variation in hardware. We will be populating hwcaps as soon
as possible for those who know we don't currently define any.
The unusual extension is the idea of a callback into the dynamic linker.
The origin of this comes from the MIPS FR0/FR1 interlinking plan which is
frequently referred to as the 'FPXX' ABI extension. The specific issue
is whether or not o32 software can rely on FR=1 mode i.e. FP64. There is
one sure fire way to do this and that is to build your module as FP64
using -mfp64 and the rest is already taken care of. However, in an ifunc
world we need the object(s) that contain ifunc resolvers and routines to
be marked with as few requirements as possible so that they will load on
the oldest/least feature-full hardware we want to support. This means
that we get no guarantee of what hardware mode is set nor whether the
mode is guaranteed not to be changed.
The primary reason for needing FR=1 is for MSA to be usable. Simply
seeing that MSA is available via a HWCAP is not enough as we have to
tell the dynamic linker to lock itself into FR=1/FP64 mode while the
ifunc's module is loaded. In fact it may not even be possible to enter
FR=1 mode because of the modules which are already loaded.
The callback interface is proposed as relatively generic to support
making different kinds of requests. The one to support MIPS FP modes is
to basically request that the current module has its FP ABI upgraded
to a specific value and report if that succeeds. I haven't reviewed the
detailed implementation of this yet but that is the general goal.
I hope that at least covers the basics of why this feature is being
proposed.
Thanks,
Matthew