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


Sorry, catching up on this thread late.

"Joseph S. Myers" <joseph@codesourcery.com> writes:
> On Fri, 16 May 2014, Matthew Fortune wrote:
>
>> I don't understand the use-case that would want a whole module (and/or
>> subset of modules within one library) to freely deploy an ISA extension
>> but have no overall marking to that extent. Such global enablement must be
>
> It's the most basic, obvious, longstanding way of using an ISA feature 
> conditionally: compile different source files with different options and 
> then use "if" conditionals to choose between them.

The MIPS toolchain has never worked like that AFAIK.  Command-line options
decide the ABI of the TU and only compatible TUs can be linked together.
The ABI of the output reflects all requirements of the input TUs.
I think that's the natural behaviour for an architecture with as many
variations as MIPS.

Of the top of my head, I don't remember any bug reports or enhancement
requests asking for a different approach, so I'm not sure the "compile
different objects with different extensions" idiom is used in practice
for MIPS.

Also, I think it would be inconsistent to treat ASEs differently from any
other part of the instruction set.  If DSOs containing a combination
of -mmsa and -mno-msa objects were marked non-msa, then presumably
we should extend that to -march, so that you can do:

   if (running on Loongson 2E)
     loongson_2e_function (...)
   else if (running on Octeon)
     octeon_function (...)
   else if (running on SB-1)
     sb1_function (...)

And if we allow it for those sorts of processor-specific extensions,
presumably we should allow it for the core ISA levels too, with one
function for MIPS IV, one for MIPS64(r1) and one for MIPS64r2.
But I think that would leave us marking every 32-bit object as MIPS
I and every 64-bit object as MIPS III, which seems less safe than what
we have now.

Thanks,
Richard


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