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: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: Matthew Fortune <Matthew dot Fortune at imgtec dot com>, Will Newton <will dot newton at linaro dot org>, Andrew Pinski <pinskia at gmail 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: Mon, 2 Jun 2014 17:30:22 +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> <Pine dot LNX dot 4 dot 64 dot 1405142119340 dot 21615 at digraph dot polyomino dot org dot uk> <6D39441BF12EF246A7ABCE6654B0235353041B at LEMAIL01 dot le dot imgtec dot org> <Pine dot LNX dot 4 dot 64 dot 1405151517380 dot 3155 at digraph dot polyomino dot org dot uk> <6D39441BF12EF246A7ABCE6654B02353531C1D at LEMAIL01 dot le dot imgtec dot org> <Pine dot LNX dot 4 dot 64 dot 1405152012500 dot 911 at digraph dot polyomino dot org dot uk> <6D39441BF12EF246A7ABCE6654B02353532EB3 at LEMAIL01 dot le dot imgtec dot org> <Pine dot LNX dot 4 dot 64 dot 1405161523480 dot 18605 at digraph dot polyomino dot org dot uk> <87ppj2f9g6 dot fsf at talisman dot default>
On Sun, 25 May 2014, Richard Sandiford wrote:
> "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.
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
joseph@codesourcery.com