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

[Matthew Fortune <Matthew dot Fortune at imgtec dot com>]

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

Apart from just the general ABI concerns having to use the GNU name in 
LLVM tools is quite strange. Rich is particularly keen on having
this changed especially if we are going to make the section loadable.
Other aspects would be that non-gnu compilers may also introduce new
attributes which would have very little to do with 'gnu'.

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

OK

Regards,
Matthew