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

[Richard Sandiford <rdsandiford at googlemail dot com>]

Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
> 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?

Yeah, I was thinking the same.  We'd use the structure for all internal
processing and convert in and out as necessary.

Thanks,
Richard