This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

I've been reviewing the .MIPS.options section to see whether it would be
a suitable place for storing this new information and from what I can tell
it would fit quite nicely. The .MIPS.options section is only emitted for
N64 currently but I don't see any technical reason why it cannot be
emitted for 32-bit or 64-bit ELFs so I would propose using it for all 3
of the most used ABIs (O32, N32, N64). Perhaps going so far as to stop
emitting the .reginfo section for O32 and N32 as that information fits
into the .MIPS.options section anyway. The structure of this section is
quite neat in that the option descriptor header states the total size
of the header+payload and therefore can be easily skipped. The maximum
payload per descriptor is 255 bytes including the 8 byte header but that
does not seem restrictive. I would add a new descriptor type and be able
to re-use a reasonable amount of existing code. There is a program header
and dynamic tag already defined for this section which are only emitted
for irix currently but that is easily resolved.

Any objections to this?

Regards,
Matthew


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]