This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

>From: Richard Sandiford []
>Sent: Tuesday, September 10, 2013 1:25 PM
>To: Maciej W. Rozycki
>Cc: Doug Gilmore;
>Subject: Re: [patch, binutils] Patch elf/mips.h for -mfp64 support.
>"Maciej W. Rozycki" <> writes:
>> On Tue, 10 Sep 2013, Richard Sandiford wrote:
>>> > 2013-09-07  Doug Gilmore <>
>>> >
>>> >    * 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?


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]