This is the mail archive of the binutils@sourceware.org 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.


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

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

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


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