This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH 1/2] Add support for O32 FPXX ABI
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- Cc: "macro\ at codesourcery dot com" <macro at codesourcery dot com>, "Joseph Myers \(joseph\ at codesourcery dot com\)" <joseph at codesourcery dot com>, "binutils\ at sourceware dot org" <binutils at sourceware dot org>, Rich Fuhler <Rich dot Fuhler at imgtec dot com>
- Date: Fri, 11 Apr 2014 09:26:42 +0100
- Subject: Re: [PATCH 1/2] Add support for O32 FPXX ABI
- Authentication-results: sourceware.org; auth=none
- References: <6D39441BF12EF246A7ABCE6654B023534DAAAB at LEMAIL01 dot le dot imgtec dot org> <87a9c0xkje dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534DC37D at LEMAIL01 dot le dot imgtec dot org> <87ha655s3i dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <6D39441BF12EF246A7ABCE6654B023534DC8CF at LEMAIL01 dot le dot imgtec dot org> <871tx9z35k dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <6D39441BF12EF246A7ABCE6654B023534DFC40 at LEMAIL01 dot le dot imgtec dot org> <878urd37t7 dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <6D39441BF12EF246A7ABCE6654B023534DFD9B at LEMAIL01 dot le dot imgtec dot org> <87fvll1ha9 dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <6D39441BF12EF246A7ABCE6654B023534E07CB at LEMAIL01 dot le dot imgtec dot org>
Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
>> So I don't think you're going to convince me that this is a good idea.
>> But at the end of the day, it's a decision that's being made for
>> branding rather than technical reasons and you guys obviously control
>> the ABI for your architecture.
>
> I don't think anyone at Imagination will try to force an ABI decision
> but as we look at formalising and recording the de-facto ABI used in the
> GNU tools then there are likely to be a few things to talk through.
Thanks.
> Independently of discussing MIPS vs GNU attributes I have been working
> on implementing the parsing of attribute sections in glibc by stealing
> code from BFD. I had not quite appreciated the complexity of the attribute
> section and the fact it has strings and uleb128 encoded values means
> everything is unaligned which is a bit frustrating. In retrospect I'm
> thinking the flexibility of the attribute section is not necessary for
> what we need and the alternative proposal of a versioned structure seems
> more desirable at this point. I'm wary of having to implement/maintain
> this in several linkers and loaders (linux/*bsd etc) but the simpler
> structure alternative would ease this.
Sounds good. I admit I hadn't looked into the format of the attributes
until now either. :-)
> Any objection to changing direction on the loadable section and
> introducing a new section at link time to contain a simple structure?
> Assuming that seems OK then I'd propose starting with:
>
> struct mips_flags_0
> {
> uint32_t version; /* mips_flags_0: version==0. */
> uint32_t e_flags2;
> };
>
> Any opinion on whether this should take a copy of the normal e_flags
> field too, and/or whether the new flags field should follow the name
> of the e_flags field or not? I can see pros and cons for including a
> copy of the e_flags field. It may be better to uncompress the flags
> so that there is a simple entry for architecture etc. This doesn't
> really need dealing with right now though.
I don't think we need to be too stingy with bytes, so personally I'd
like to go for the decompressed format. The problem with flags is
that a lot of the things we want to model are enumerations, and if
you only define a 32-bit flags field, the tendancy is to allocate
enum fields that might end up being too small.
E.g., completely off the top of my head:
struct mips_flags_0
{
uint32_t version; /* mips_flags_0: version==0. */
uint8_t isa_level; /* 1-5, 32, 64 */
uint8_t isa_rev; /* 0 for MIPS V and below, 1-5 so far otherwise */
uint8_t gpr_size; /* log2, 5, 6 or (possibly for r5900/r7900) 7 */
uint8_t fpr_size; /* log2, 5, 6 or (for MSA128) 7, 0 for FPxx */
uint32_t isa_ext; /* enumeration of processor-specific extensions */
uint32_t ases; /* bitmask of ASEs used */
uint32_t flags1; /* bitmask of general flags */
};
We could even throw in a second flags field to round it to a 64-bit boundary.
The flags should include the hard/soft-float distinction and (possibly)
single/double float.
It'd probably make sense for the ases field to include the ASEs that
already have ELF flags, so all the information is available in one place.
I don't mind either way about the other ELF flags.
Just a suggestion of course.
Thanks,
Richard