This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH] MIPS/BFD: Correct/clean up ELF FP attribute warning messages
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.