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:
>> Matthew Fortune <> writes:
> ...
>> > Perhaps call it PT_MIPS_ATTRIBUTES or PT_GNU_ATTRIBUTES if this were
>> > done for all architectures.
>> Yeah.  Might as well make it PT_GNU_ATTRIBUTES, even if it's something
>> that targets have to buy into.  Probably worth sending a separate RFC to
>> the list for that.
> I've had some discussion about this with Rich (now on cc). The current
> thinking is that we don't want to have the MIPS ABI any more dependent on
> the GNU attribute section but instead would prefer to migrate to a MIPS
> attribute section. In order to achieve the migration then we would have to
> do something like:
> 1) use the same attribute numbers for the FP abi and MSA abi as used in the
>    GNU attributes section
> 2) At link time, if the FP or MSA attribute is set in the gnu attribute
>    section then copy it to the MIPS attribute section (or if already set
>    check they match)
> 3) In the output object only emit the MIPS attribute section (though I
>    guess it would do no harm to emit both).
> 4) Perhaps emit both gnu and MIPS attributes in the assembler for
>    backwards compatibility with older linkers. I think it would be
>    sufficient to just do this when inferring an attribute from module options.
>    The explicit .gnu_attribute and .mips_attribute would just set their
>    Respective attributes but we would be phasing out the explicit use of such
>    attributes anyway.
> How does that sound? If it is OK would you be happy to review other aspects
> of the patch under the assumption that the linker would use this newly
> proposed program header scheme on the executables? It will take a few days
> to rework this as I have to educate glibc about parsing attribute sections
> and retest.

I understand why you'd prefer a MIPS gloss to the section names but it
seems a bit late to change it now.  Having the same information under
two different section names is just going to create a lot of unnecessary

Maybe the others on cc: feel more positively about it than me though.

Since the program header is new, calling it PT_MIPS_ATTRIBUTES would be
fine with me.  I slightly prefered PT_GNU_ATTRIBUTES for consistency
with the section name but at least there'd be no compatibility problem
with treating as a MIPS-specific header.  The meaning of the attributes
is target-dependent anyway.


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