This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [PATCHv2, MIPS] Add support for O32 FPXX and program header based ABI information


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]