This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
RE: [PATCHv2, MIPS] Add support for O32 FPXX and program header based ABI information
- From: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- To: Joseph Myers <joseph at codesourcery dot com>, Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: Will Newton <will dot newton at linaro dot org>, Andrew Pinski <pinskia at gmail dot com>, Rich Fuhler <Rich dot Fuhler at imgtec dot com>, "macro at codesourcery dot com" <macro at codesourcery dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Tue, 3 Jun 2014 17:46:36 +0000
- Subject: RE: [PATCHv2, MIPS] Add support for O32 FPXX and program header based ABI information
- Authentication-results: sourceware.org; auth=none
- References: <6D39441BF12EF246A7ABCE6654B0235352F38D at LEMAIL01 dot le dot imgtec dot org> <Pine dot LNX dot 4 dot 64 dot 1405141549300 dot 16785 at digraph dot polyomino dot org dot uk> <6D39441BF12EF246A7ABCE6654B0235352FF45 at LEMAIL01 dot le dot imgtec dot org> <Pine dot LNX dot 4 dot 64 dot 1405142119340 dot 21615 at digraph dot polyomino dot org dot uk> <6D39441BF12EF246A7ABCE6654B0235353041B at LEMAIL01 dot le dot imgtec dot org> <Pine dot LNX dot 4 dot 64 dot 1405151517380 dot 3155 at digraph dot polyomino dot org dot uk> <6D39441BF12EF246A7ABCE6654B02353531C1D at LEMAIL01 dot le dot imgtec dot org> <Pine dot LNX dot 4 dot 64 dot 1405152012500 dot 911 at digraph dot polyomino dot org dot uk> <6D39441BF12EF246A7ABCE6654B02353532EB3 at LEMAIL01 dot le dot imgtec dot org> <Pine dot LNX dot 4 dot 64 dot 1405161523480 dot 18605 at digraph dot polyomino dot org dot uk> <87ppj2f9g6 dot fsf at talisman dot default> <Pine dot LNX dot 4 dot 64 dot 1406021726390 dot 19591 at digraph dot polyomino dot org dot uk> <87lhtf9pgq dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <Pine dot LNX dot 4 dot 64 dot 1406022157570 dot 27099 at digraph dot polyomino dot org dot uk> <87wqcya208 dot fsf at talisman dot default> <Pine dot LNX dot 4 dot 64 dot 1406031632280 dot 12421 at digraph dot polyomino dot org dot uk>
Joseph Myers <joseph@codesourcery.com> writes:
> > Similarly if you link -mmdmx and -mno-mdmx code together you get an
> > -mmdmx output.
>
> But that "-mmdmx output" will run on hardware without the relevant
> feature, if there are runtime checks, I presume
As it stands there are no checks between hardware support and executables
or shared libraries. So (for what I'm calling normal usage) an executable
that includes -mmdmx output will simply crash when run on a non-mdmx
core. I am defining normal usage to be those people who don't know how
to write clever run-time checks. Since there is no way for a userland
process to inspect whether the core supports mdmx currently then there is
no way to improve on this. The introduction of HWCAP bits (specifically
for MSA but not restricted to that) allows us to do better now for my
'normal' usage case and also start to support the idea of a user doing
runtime checks on MIPS.
> (otherwise the MSA case
> would be handled by whatever handles -mmdmx rather than any new checks in
> glibc being proposed that are specific to MSA).
We could go back and define HWCAP bits for the other ASEs and perform
appropriate checks for them as well as new ASEs. It seems like a moot
point though given there has been no such dynamic linker checks for MDMX
so far and I believe there is essentially just one implementation of MDMX.
For MIPS3D I'm not sure there are any production implementations. However,
given there is generic support for up to 64 HWCAP bits then assigning one
to each of the pre-existing ASEs won't steal too many of those bits.
To support the scenario that you pointed me towards (x86_64 multiarch I
believe it was) then the only difference for MIPS vs x86_64 would be that
the source wrappers, which are used to rename functions and define special
sections, would also need to have a pragma or other source level directive
to enable MSA for the remaining functions in the file. This allows us to
differentiate between the 'globally enable a feature' via command line
and 'hide the usage of the feature' for user-supplied runtime checks.
The thing which MIPS has and many(/all?) other architectures lack is
information stored in an executable or DSO which accurately states their
requirements. This is the basis for suggestion we should do whole
executable and whole DSO checks for MIPS (as well as supporting the user
supplied runtime detection case).
Regards,
Matthew