This is the mail archive of the 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 Sun, 25 May 2014, Richard Sandiford wrote:

> "Joseph S. Myers" <> 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.

Linking objects built -mdsp and -mno-dsp, or -march=mips32r2 and 
-march=mips64r2, works for me.  The result does get marked as having the 
appropriate superset instruction set - are you saying there is some 
existing Solaris-style check somewhere (where?) that disallows such a 
combination from executing on hardware lacking the features for all of the 
objects, even if the relevant instructions are only executed 
conditionally?  Or that some other combinations get disallowed at static 
link time?

Joseph S. Myers

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