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: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Matthew Fortune <Matthew dot Fortune at imgtec 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: Wed, 14 May 2014 21:29:13 +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>
On Wed, 14 May 2014, Matthew Fortune wrote:
> Thanks for the feedback. Comments inline.
>
> Joseph Myers <joseph@codesourcery.com> writes:
> > On Wed, 14 May 2014, Matthew Fortune wrote:
> >
> > > I have not yet tested all the FP ABI combinations but have covered the
> > > ones which are related to FPXX. I am working through the rest as well
> > > as n32/n64 ABIs.
> >
> > I'd like to understand how all the various combinations of ABIs of objects
> > and old and new compilers, binutils and libc (and kernel?) work. Could
> > you add information to the wiki page
> > <https://dmz-portal.mips.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinking>
> > about this?
>
> Absolutely. I tried to keep the information on compatibility specifically
> about the three (fp32, fpxx, fp64) ABIs as newly defined. This is
> mainly so that the spec can be applied to any set of tools regardless of
> specific implementation issues. I still ended up with some GCC/binutils/glibc
> centric ideas in there but that was not intentional.
Indeed, that page seems to do rather better on how things work with
all-new objects, than on what happens with old objects, or objects built
with one of GCC and binutils new and the other old.
> I have not proposed any such logic. My opinion is that this is not a
> critical thing to have but if we can find a sensible solution then
> that is fine. Other aspects of this work improve the error checking that
> I do not believe any existing dynamic linker handles i.e. checking that
> soft and hard float shared libraries/executables are not linked.
The mood now is to do better in future for such cases by expecting each
new ABI (even for a new architecture) to have a unique dynamic linker
name. (Of course that doesn't help for existing MIPS ABIs where the
dynamic linker names are already fixed.)
> > (It's possible the old-dynamic-linker case can be handled by setting the
> > ABI version, depending on how far the bitrot discussed in
> > <https://sourceware.org/ml/libc-alpha/2014-01/msg00375.html> (which I
> > referred to in <https://sourceware.org/ml/binutils/2014-04/msg00237.html>)
> > extends. Or if that won't work, making FR=1 objects contain a reference
> > to a new symbol glibc exports at version GLIBC_2.20 would work.)
>
> I'd be happy with setting a new ABI version for FP64. Reading through the
> code it looks like this will lead to existing dynamic linkers rejecting
> the ELF so could work nicely. I'd be somewhat wary of having to do something
> like reference a new symbol to get the desired behaviour. I'll make sure to
> discuss this with Richard on the binutils thread if he is not following this
> thread in detail.
I suspect some bitrot in the existing feature may well need fixing first
(whether in binutils or glibc), but it's certainly the natural feature to
use if possible, being intended to ensure that binaries using new ELF
features are rejected by older dynamic linkers.
> > 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 options
> > 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 using
> 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).
--
Joseph S. Myers
joseph@codesourcery.com