This is the mail archive of the
mailing list for the binutils project.
Re: [patch, binutils] Patch elf/mips.h for -mfp64 support.
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: "Maciej W. Rozycki" <macro at codesourcery dot com>
- Cc: Doug Gilmore <Doug dot Gilmore at imgtec dot com>, <binutils at sourceware dot org>
- Date: Tue, 10 Sep 2013 21:25:48 +0100
- Subject: Re: [patch, binutils] Patch elf/mips.h for -mfp64 support.
- Authentication-results: sourceware.org; auth=none
- References: <522E6DDF dot 10909 at imgtec dot com> <87sixdf64s dot fsf at talisman dot default> <alpine dot DEB dot 1 dot 10 dot 1309100948050 dot 29360 at tp dot orcam dot me dot uk>
"Maciej W. Rozycki" <firstname.lastname@example.org> writes:
> On Tue, 10 Sep 2013, Richard Sandiford wrote:
>> > 2013-09-07 Doug Gilmore <email@example.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:
>> * mips.h (EF_MIPS_32BITMODE): New e_flags bit.
>> * elfxx-mips.c (_bfd_mips_elf_print_private_bfd_data): Handle
>> * readelf.c (get_machine_flags): Handle EF_MIPS_32BITMODE.
>> * 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:
>> 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!