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

[Joseph S. Myers]

On Thu, 15 May 2014, Matthew Fortune wrote:

> > 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:
> 
> as foo.s
> ===
> .set push
> .set msa
> <msa function>
> .set pop
> ===
> 
> The resulting object will then 'not' be marked as using the MSA ASE.

That indicates to me that the GCC -mmsa option should not imply the 
assembler -mmsa option, so that users can use -mmsa with GCC exactly the 
same way they use -mavx (for example) - that is, -mmsa should result in 
the push/pop in the .s file.  Otherwise, how do you expect users compiling 
one source file with -mmsa and one without to get their final binary not 
marked as requiring MSA?

-- 
Joseph S. Myers
joseph@codesourcery.com