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:
> Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
> > 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.
> 
> Don't mind either way on that one.  I hope we're not likely to add yet
> more ABIs (surely 6 is enough) and the distinction between o32,
> n32 and n64 really has to be made in the ELF header anyway.
> But I don't see it doing any harm.
> 
> Perhaps also an ABI revision number, so that we can bump it when adding
> things that old loaders won't be able to handle correctly.
> E.g. the suggestion for ifuncs was that we'd add a new dynamic tag for
> the start of the implicitly-relocated local GOT.
> 
> When setting the revision to something higher than what we have now, we
> could use a dummy relocation to choke old loaders.
> 
> > 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?
> 
> Probably once we define the structure we'll want to emit it
> unconditionally.

OK. I expect the linker would then want to check e_flags and gnu attributes agree with the content of the structure (if present). It may then be easiest to move all the e_flag / attribute checks to be performed using the structure and have the linker infer the structure content when it is not present in an input object. Any thoughts on that side of things?

Regards,
Matthew