Re: [PATCH 1/2] Add support for O32 FPXX ABI

[Richard Sandiford <rdsandiford at googlemail dot com>]

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