Matthew Fortune <matthew.fort...@imgtec.com> writes:
>> I think instead we should have a configuration switch that allows a
>> particular -mfp option to be inserted alongside -mabi=32 if no explicit
>> -mfp is given. This is how most --with options work. Maybe --with-fp-
>> 32={32|64|xx}? Specific triples could set a default value if they like.
>> E.g. the MTI, SDE and mipsisa* ones would probably want to default to --
>> with-32-fp=xx. Triples aimed at MIPS IV and below would stay as they
>> are. (MIPS IV is sometimes used with -mabi=32.)
>>
>> --with-fp-32 isn't the greatest name but is at least consistent with
>> --with-arch-32 and -mabi=32. Maybe --with-fp-32=64 is so weird that
>> breaking consistency is better though.
>
> Tying the use of fpxx by default to a configure time setting is OK with
> me. When enabled it would still have to follow the rules as defined in
> the design in that it can only apply to architectures that can support
> the variant.
Right. It's really equivalent to putting the -mfp on every command line
that doesn't have one.
> Currently that means everything but mips1.
Yeah, using -mips1 on a --with-{o}32-fp=xx toolchain would be an error.
> I'm not sure this is the same as tying an ABI to an architecture as
> both fp32 and fpxx are O32 and link compatible. Perhaps the configure
> switch would be --with-o32-fp={32|64|xx}. This shows it is just an O32
> related setting.
What I meant is that -march= and -mips shouldn't imply a different
-mfp setting. The -mfp setting should be self-contained and it should
be an error if the architecture isn't compatible.
We might be in violent agreement here :-) Like I say, I was just a
bit worried by the earlier -mips32r2 thing because there was a time
when a -mips option really could imply things like -mabi, -mgp and -mfp.
--with-o32-fp would be OK with me. I'm just worried about the ABI
being spelt differently from -mabi=, but there's probably no perfect
alternative.
>> > Currently newlib's implementation is assembly code with no
>> > .gnu_attributes. Under the rules above this would start to be
>> > implicitly tagged as gnu_attribute 4,1 (fp32). Any thoughts on how we
>> > transition this to fpxx and still have the modules buildable with old
>> > tools as well? I'm not sure if it will be acceptable to say that it
>> > has to be rewritten in C.
>>
>> If it's assembled as -mfpxx then it'll be implicitly tagged with the new
>> .gnu_attribute rather than 4,1. If it's not assembled as -mfpxx then
>> 4,1 would be the right choice.
>
> So this would be dependent on the build system ensuring -mfpxx is passed
> as appropriate if the toolchain supports it. There is some risk in this
> too if the existing code (which I know is not fpxx safe) gets built with
> a new toolchain then it will be tagged as fpxx. I wonder if this tells
> us that command line options cannot safely set the FP ABI away from the
> default. Instead only the .module and .gnu_attribute can set it as only
> the source code can know what FP mode it was written for. The change to
> your 4 points above would be that the module level setting is not
> impacted by the command line -mfp options.
I don't think that's necessary. For one thing, there's always the
problem with unannotated asm code that the command-line options might
be wrong. There's often not much we can do about that. E.g. we have to
assume that code assembled as -mabi=n32 really is n32 code and not n64
code (and produce a 32-bit rather than 64-bit ELF). There's no way of
hedging our bets in that case: we have to pick an ABI.
For another, leaving the attribute as the default 0 makes the object
compatible with everything, so a file assembled with the wrong -mfpyy
could still be linked with other -mfpyy files. I don't think it gives
us anything extra.
The interaction between .module and command-line options should be the
same for all .module/.set options.
Thanks,
Richard
