This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
RE: [PATCH 1/2] Add support for O32 FPXX ABI
- From: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- To: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: "macro at codesourcery dot com" <macro at codesourcery dot com>, "Joseph Myers (joseph at codesourcery dot com)" <joseph at codesourcery dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>, Rich Fuhler <Rich dot Fuhler at imgtec dot com>, Doug Gilmore <Doug dot Gilmore at imgtec dot com>
- Date: Tue, 6 May 2014 14:08:31 +0000
- Subject: RE: [PATCH 1/2] Add support for O32 FPXX ABI
- Authentication-results: sourceware.org; auth=none
- References: <6D39441BF12EF246A7ABCE6654B023534DAAAB at LEMAIL01 dot le dot imgtec dot org> <6D39441BF12EF246A7ABCE6654B023534DFD9B at LEMAIL01 dot le dot imgtec dot org> <87fvll1ha9 dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <6D39441BF12EF246A7ABCE6654B023534E07CB at LEMAIL01 dot le dot imgtec dot org> <87k3awnuf1 dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534E0F50 at LEMAIL01 dot le dot imgtec dot org> <87ppknzv7m dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534E16D7 at LEMAIL01 dot le dot imgtec dot org> <877g6vzpj1 dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534E3030 at LEMAIL01 dot le dot imgtec dot org> <87eh0yl4xx dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534E3AA8 at LEMAIL01 dot le dot imgtec dot org> <87d2ghk7fu dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023535127C8 at LEMAIL01 dot le dot imgtec dot org> <87r44mve6s dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <6D39441BF12EF246A7ABCE6654B02353512A10 at LEMAIL01 dot le dot imgtec dot org> <87r44leu34 dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B0235351D76A at LEMAIL01 dot le dot imgtec dot org> <53640082 dot 6070703 at imgtec dot com> <6D39441BF12EF246A7ABCE6654B023535214A4 at LEMAIL01 dot le dot imgtec dot org> <87lhufaxmz dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com>
> So I'm planning to commit a patch to update the code that checks and
> prints the tags. Hopefully it should be easy to rebase yours on top.
Fine with me. That code is/was insane. I was merely going along with it.
> Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
> > + /* If floating-point code has been seen and the module is
> single-float
> > + then give this precedence over the double-precision cases below.
> > + Single-float can theoretically be used with any width register.
> */
> > + else if (mips_seen_fp_code == TRUE
> > + && file_mips_opts.single_float == 1)
> > + fpabi = Val_GNU_MIPS_ABI_FP_SINGLE;
> >
> > This is not OK. As we don't know if the user wrote .module singlefloat
> or used
> > -msingle-float. If it was .module then this shows intent that the code
> in this
> > module is designed for single-float so that would be OK.
>
> But .module should act like the corresponding command-line option,
> and vice versa. I don't think any extra trust should be given to
> one over the other.
>
> I think we need to keep the interface as simple as possible.
I agree, but we also need safety.
> > I propose a further option to fix this. -minfer-abi and .module infer-
> fpabi.
>
> No!!! :-) Even more options would just make things unnecessarily
> complicated.
> Anything passing the command-line options or generating the .module
> should
> say what the ABI is instead.
Are you saying you think the user should have to write .gnu_attribute 4,5 or .gnu_attribute 4,6 to get any FP ABI attribute other than 'any'? Your comment below suggests not...
> The general principle is that an asm file can include code that requires
> features outside the module-level setting. We should never infer
> anything about the global FPU ABI from something like an ADD.D that
> we happen to see. It might be that the ADD.D is part of an ifunc
> (or similar mechanism) that only runs when an FPU is available.
>
> IMO we should just leave the FPU ABI as "any" unless a command-line
> option,
> .module or .gnu_attribute says what the ABI actually is.
My problem is with the command line options, not .module. The writer of the code has control over .module but not over the command line options. I.e. consider a toolchain prepared with --with-fp=xx and a toolchain prepared with --with-fp=32/default. Depending on the toolchain used then any hand-crafted assembly code may be tagged with an incompatible FP ABI. While we could validly assume that options like -mfpxx won't be used explicitly by people building code that they did not write... implied options from the toolchain mean that the compiler driver may use them. For FPXX to work we have to enable linux distributions to include a compiler that is FPXX by default to facilitate the transition but do so safely. Any thoughts on how to make this safe?
The code I referred to as being broken when testing GCC was mips16.S from libgcc. It is a niche case given its purpose but demonstrates the problems of pre-existing FP code.
Regards,
Matthew