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

["Maciej W. Rozycki" <macro at codesourcery dot com>]

On Wed, 21 Nov 2012, Richard Sandiford wrote:

> >  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.

 Yes, as I noted this is equivalent to the attribute being zero (BFD does 
not propagate ".gnu_attribute 4,0" to output, it discards it).

> 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.

 I agree, in this case additional variables might be needed when/if we 
have more tags defined.  I have no strong preference on the static 
variable; in fact I think your proposal is a mite cleaner (no local state 
buried in a corner).

> 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.

 Agreed, quoting the options makes sense to me and I didn't like these 
"soft float" messages either, I just didn't feel motivated enough to think 
what to do about them. ;)

> Looks good otherwise.

 OK, thanks for the quick review, I'll post an update soon.

  Maciej