[PATCH] MIPS/BFD: Correct/clean up ELF FP attribute warning messages

[Richard Sandiford]

"Maciej W. Rozycki" <macro@codesourcery.com> writes:
> On Mon, 19 Nov 2012, Maciej W. Rozycki wrote:
>>  Meanwhile I'll look into keeping that first input BFD file name for 
>> reporting.  And actually, after a bit of thinking, I believe it may even 
>> make sense to say e.g.:
>> 
>> Warning: foobar uses -mdouble-float (set by foo.o), baz.o uses
>> -mips32r2 -mfp64
>> 
>> to emphasize both the ABI chosen for output and where it came from.  What 
>> do you think?
>
>  As a follow-up, here's an outline in implementation terms of what I have 
> had in my mind.  I have decided to keep the name of the input BFD locally 
> after all (rather than say attaching it to the output BFD structure) for 
> one reason and a half:
>
> 1.0. The way attribute merging is performed is target specific and for 
>      other targets it may well not be the first input that determines the 
>      final (or any intermediate) attribute setting, e.g. it may change as 
>      inputs are processed.
>
> 1.5. And this is actually already the case for the MIPS target, that I 
>      didn't notice outright, that is any inputs that have the value of the 
>      FP ABI attribute set to zero (absent normally as that setting is 
>      ignored by BFD on output, although still processed correctly when 
>      present) do not influence the FP ABI and cannot conflict with 
>      anything.  That is it is actually the first input with a non-zero FP 
>      ABI attribute that determines the ABI.
>
> These observations are reflected in the change proposed below.

As far as 1.5 goes: inputs don't need to have the attribute at all.
Asm code and pure data might not have them, and we still need to accept
objects from before the attributes were defined.

So logically I think we need a separate variable for each tag,
Obviously we only have one tag here anyway, but the name of the
new bfd variable should reflect that it's just for the FP tag.

I'd prefer a mips_elf_obj_tdata rather than a static variable.
I realise that's one extra pointer per bfd, but this isn't a
lean structure.

While you're changing the errors anyway, it might be worth replacing
the two quoted options with %s and using -msoft-float and -mhard-float
instead of "soft float" and "hard float".  Hopefully that wins on user
interface grounds (we consistently reference an option) and means we
always use the same format string.  Just a suggestion though.

Looks good otherwise.

Richard