This is the mail archive of the 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 <> writes:
> Richard Sandiford <> 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.


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