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


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.

> > And then somehow get that to be positioned immediately after the notes
> > segment.
> 
> Yeah, at least in the case where it's loadable (and maybe otherwise
> too).
> In the bfd linker this would be done by putting the .gnu_attributes in
> the appropriate place in the linker script.

I realised this after sending my email, thanks.

Regards,
Matthew


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