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


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:
>> >> 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.

How much code would it save though?  It means you don't have to define
a new header, but that's only a small saving.

I agree it'd be possible to use .MIPS.options, but in some ways it seems
a bit heavyweight for what we want.  Like with PT_NOTE, looking up
the data would involve a search for the right kind.  In this case
we'd be searching for an integer rather than a string, so it's much
less of a problem, but it still seems like an unnecessary overhead.
FWIW, looking at an n64 libc.so I have lying around, the .MIPS.options
is 0xe948 bytes in size.

I suppose you could add a rule that the new kind needs to come first,
but that doesn't seem in the spirit of the thing.  If we're adding
special rules like that then we might as well add a new header instead.

Also, like you say, it would involve either a change to the ELF32 ABIs
or having duplicated information there.  We'd probably have to go for
the duplicated information since .reginfo is part of the psABI.

I'm not totally opposed or anything.  I'm just not sure it buys much.

Thanks,
Richard


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