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

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.

Thanks,
Richard