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

[Matthew Fortune <Matthew dot Fortune at imgtec dot com>]

Richard Sandiford <rdsandiford@googlemail.com> writes:
> > 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.

No objections here. Perhaps including ABI would also be useful.

Since you mention the flagging of new ASEs I wonder if we can consider
that in more detail. When we need to flag something that is not already
included in the e_flags or attributes then I guess the assembler would
need to be emitting this structure too?

Regards,
Matthew