This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH 1/2] Add support for O32 FPXX ABI
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Matthew Fortune <Matthew dot Fortune at imgtec 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, 06 May 2014 15:39:03 +0100
- 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> <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> <6D39441BF12EF246A7ABCE6654B0235352163E at LEMAIL01 dot le dot imgtec dot org>
Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
>> > I propose a further option to fix this. -minfer-abi and .module infer-
>> No!!! :-) Even more options would just make things unnecessarily
>> Anything passing the command-line options or generating the .module
>> 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 command line, .module and .gnu_attribute can all be used to set
the FP ABI.
>> 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
>> .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?
We fundamentally can't make it safe, in the sense that an asm file
without an explicit annotation by definition doesn't say what ABI
it uses. The same problem occurs if using inline asms in a C compilation.
If you use a header file with floating-point inline asms, those asms
will be included in code whose .module or .gnu_attribute is dictated by
the GCC command-line options. There's no guarantee that the inline asms
are safe for all such .modules or .gnu_attributes. The problem isn't
specific to the assembler command line.
If command-line options are given, we need to assume that that's the
output that the user wants. We can detect cases where there are
"obvious" breaches of the ABI outside of an appropriate push/pop, but
IMO it should be that way around: assume that the command-line, .module
or .gnu_attribute (in increasing order of precedence) specify the ABI
correctly and report a diagnostic when the code seems to be something