RE: [patch, binutils] Patch elf/mips.h for -mfp64 support.

[Doug Gilmore <Doug dot Gilmore at imgtec dot com>]

>From: Richard Sandiford [rdsandiford@googlemail.com]
>Sent: Tuesday, September 10, 2013 1:25 PM
>To: Maciej W. Rozycki
>Cc: Doug Gilmore; binutils@sourceware.org
>Subject: Re: [patch, binutils] Patch elf/mips.h for -mfp64 support.
>
>"Maciej W. Rozycki" <macro@codesourcery.com> writes:
>> On Tue, 10 Sep 2013, Richard Sandiford wrote:
>>
>>> > 2013-09-07  Doug Gilmore <doug.gilmore@imgtec.com>
>>> >
>>> >    * mips.h (EF_MIPS_32BITMODE): New e_flags bit.
>>> >    * elfxx-mips.c check for EF_MIPS_32BITMODE, print [32bitfp64]
>>> >    * readelf.c check for EF_MIPS_32BITMODE, print 32bitfp64
>>> >    * tc-mips.c When it is appropriate, set EF_MIPS_32BITMODE.
>>>
>>> The changelogs should be something like:
>>>
>>> include/elf/ChangeLog:
>>>      * mips.h (EF_MIPS_32BITMODE): New e_flags bit.
>>>
>>> bfd/ChangeLog:
>>>      * elfxx-mips.c (_bfd_mips_elf_print_private_bfd_data): Handle
>>>      EF_MIPS_32BITMODE.
>>>
>>> binutils/ChangeLog:
>>>      * readelf.c (get_machine_flags): Handle EF_MIPS_32BITMODE.
>>>
>>> gas/ChangeLog:
>>>      * config/tc-mips.c (mips_elf_final_processing): Set
>>>      EF_MIPS_32BITMODE for -mgp32 -mfp64, removing old FIXME.
>>>
>>> (One of those cases where the changelogs are almost longer than the patch.)
>>>
>>> OK otherwise, thanks.
>>
>>  Well the entries need to match code too, i.e. refer to
>> EF_MIPS_32BITMODE_FP64 rather than EF_MIPS_32BITMODE.
>
>Oops, yes indeed...
Yes, thanks Maciej for catching this, I'll update the ChangeLog files accordingly.
>
>>  Also how about just EF_MIPS_FP64 for brevity and to match the name
>> chosen for the corresponding attribute?
>
>That might be a bit confusing though, since we only set it for -mgp32 -mfp64,
>not normal -mgp64 -mfp64.
OK, then I should keep using EF_MIPS_32BITMODE_FP64, right?

Is OK if Steve Ellcey commits this change in for me?

Thanks,

Doug
>
>>> I suppose this means we have only three genuinely free bits left:
>>>
>>> 0x00000800
>>> 0x00008000 (currently part of EF_MIPS_ABI but not used)
>>> 0x01000000 (currently part of EF_MIPS_ARCH_ASE but not used)
>>
>>  Indeed, we may need to switch to ELF notes at one point.  One of the bits
>> left, presumably 0x00000800, may be useful to denote the need to refer
>> interpreters to such notes (for performance reasons, e.g. for the kernel
>> so that it doesn't look notes up where there isn't one).
>
>Yeah, keeping 0x800 in reserve as some kind of extension escape sounds
>like a good idea to me FWIW.  I think you tend to hear about these new
>flags before I do, so please push for that if you get chance!
>
>Thanks,
>Richard