[PATCH 1/2] Add support for O32 FPXX ABI
Matthew Fortune
Matthew.Fortune@imgtec.com
Fri Apr 11 13:14:00 GMT 2014
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
More information about the Binutils
mailing list