[MIPS] Reserve a .gnu_attribute value

[Moore, Catherine]

> -----Original Message-----
> From: Maciej W. Rozycki [mailto:macro@linux-mips.org]
> Sent: Thursday, July 09, 2015 3:58 PM
> To: Moore, Catherine
> Cc: Richard Sandiford; Richard Sandiford; binutils@sourceware.org;
> andrew.bennett@imgtec.com; Matthew Fortune
> Subject: RE: [MIPS] Reserve a .gnu_attribute value
> 
> On Wed, 8 Jul 2015, Moore, Catherine wrote:
> 
> > > > > diff --git a/binutils/readelf.c b/binutils/readelf.c index
> > > > > 398a165..86cfd26 100644
> > > > > --- a/binutils/readelf.c
> > > > > +++ b/binutils/readelf.c
> > > > > @@ -13197,6 +13197,9 @@ print_mips_fp_abi_value (int val)
> > > > >      case Val_GNU_MIPS_ABI_FP_64A:
> > > > >        printf (_("Hard float compat (32-bit CPU, 64-bit FPU)\n"));
> > > > >        break;
> > > > > +    case Val_GNU_MIPS_ABI_FP_NAN2008 :
> > > > > +      printf (_("NaN 2008 compatibility\n"));
> > > > > +      break;
> > > >
> > > > No space before ":"
> > > >
> > > > OK with that change, thanks.
> > >
> > >  Shouldn't there be more case values?
> `Val_GNU_MIPS_ABI_FP_NAN2008'
> > > was ORed with the lower bits, e.g. `Val_GNU_MIPS_ABI_FP_DOUBLE'.
> >
> > I'm trying to provide a minimal implementation that will ensure that
> > Val_GNU_MIPS_ABI_FP_NAN2008 doesn't get used for anything else.
> There
> > isn't anything in the upstream repository that will generate or use
> > that bit unless it's by mistake.  I thought it would be best to have
> > readelf just indicate that the bit was in use.
> 
>  Sure, however as proposed with your change
> `Val_GNU_MIPS_ABI_FP_NAN2008'
> is merely an enum value, it does not indicate in any way that the whole
> 8-15 range has indeed been taken.
> 
>  Also 0 is `Val_GNU_MIPS_ABI_FP_ANY' i.e. usually (in code generated by
> recent GCC) means no-fp, so consequently the value of 8 won't normally be
> there.  The usual case will be 9, for `Val_GNU_MIPS_ABI_FP_DOUBLE' and
> 2008 NaN; `Val_GNU_MIPS_ABI_FP_SINGLE' and consequently 10 is also a
> reasonable case.  For these values `???' will still be printed.
> 
>  FAOD I don't want to be a hindrance for you with this change, I just wonder
> if we can do a better job to cheaply avoid a potential ABI clash here.  It's not
> like we're short of numeric values available, wasting 8 of them is I think not a
> big deal.
> 
>  Maybe simply masking the bit/value out in `print_mips_fp_abi_value' and
> merely documenting the range in include/elf/mips.h will be a better way?
> This way the FP ABI will be reported correctly and you'll still have the
> EF_MIPS_NAN2008 ELF file header bit to tell legacy- and 2008-NaN binaries
> apart.  Win-win?
> 

This is a slight variation on the original patch that I think will address Maciej's concern.
I've added a comment to include/elf/mips.h to indicate the range.  Instead of printing (readelf) or ignoring (gas) the compatibility value, it is now masked out.  I've also updated the testsuite to reflect the current state of the patch.
I've already applied the original patch.  Is this amendment OK to commit?
Thanks,
Catherine

-------------- next part --------------
A non-text attachment was scrubbed...
Name: fpattr-compat.cl
Type: application/octet-stream
Size: 967 bytes
Desc: fpattr-compat.cl
URL: <https://sourceware.org/pipermail/binutils/attachments/20150716/7d72fb01/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fpattr-compat.patch
Type: application/octet-stream
Size: 9615 bytes
Desc: fpattr-compat.patch
URL: <https://sourceware.org/pipermail/binutils/attachments/20150716/7d72fb01/attachment-0001.obj>