This is the mail archive of the
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>
- Cc: Will Newton <will dot newton at linaro dot org>, Andrew Pinski <pinskia at gmail dot com>, Richard Sandiford <rdsandiford at googlemail 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: Thu, 15 May 2014 06:36:07 +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>
Joseph Myers <firstname.lastname@example.org> writes:
> On Wed, 14 May 2014, Matthew Fortune wrote:
> > Joseph Myers <email@example.com> writes:
> > > It's normal and OK for code to do things like
> > >
> > > if (msa_present)
> > > func_msa ();
> > > else
> > > func_non_msa ();
> > >
> > > where the two functions are in different source files, built with
> > > different options. Or to do the equivalent with IFUNCs. Or to use the
> > > "target" GCC attribute to have the functions built with different
> > > in the same .o file. So the presence of MSA instructions in an object
> > > file can't be taken to indicate user intent that the final linked
> > > executable or shared library requires MSA.
> > Absolutely. Such an executable/shared library would not be marked as
> > MSA (because it may not depending on runtime). However an executable that
> > is simply built with MSA enabled throughout will be marked as using the
> > MSA ASE unconditionally. It is the simple case of unconditionally using
> > MSA that I would like to improve error checking for.
> That suggests you need a new -mlink-require-msa or similar option to put
> this setting in an executable / shared library, given that existing
> practice is that use of an option such as -mmsa for some objects does not
> imply an MSA requirement for the result of linking - users don't expect to
> need any special options for code with that sort of runtime checking, they
> just build different objects with different options (and you're unlikely
> to get -mmsa used for all objects in any executable / shared library - if
> nothing else, crt*.o, libgcc etc. probably aren't built with -mmsa - so
> merging on the basis that MSA + non-MSA = non-MSA won't help).
Binutils is tuned for the simple case of users writing code that does not do
runtime checks. i.e. as foo.s -mmsa results in an object that says it uses
the MSA ASE. The merging of ASE usage into an executable or shared library
is an 'OR' so MSA + non-MSA == MSA. To create a shared library or executable
which includes runtime checks before executing any MSA code then the MSA
code has to be hidden:
The resulting object will then 'not' be marked as using the MSA ASE.
This gives us two classes of binary. The ones which include runtime
checks before using MSA are safe by design. The ones which the
average user will build are not 100% safe and can only rely on search
paths being set correctly and MSA-enabled libraries not being found in
a non-MSA search path.
The proposal is just to add a small amount of extra functionality which
serves two purposes:
1) If a program running on non-MSA hardware ends up linking with an
MSA library then the user is informed via link error instead of
2) If (1) occurs and there are still search paths to look in then the
dynamic linker may still resolve the dependency with a library that
can be loaded on the current hardware.
This is a natural extension of the functionality added by FPXX as the
FPXX logic includes this kind of link time rejection in the hope that
a compatible object will be found later.
Thinking about something I wrote last night...
I said I was wrong to have included the HWCAP_MIPS_UFR feature in
HWCAP_IMPORTANT but actually it is probably the right thing to do
as it serves to define a search path (ufr) where FP64 libraries
can be placed.