This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH 1/2] Add support for O32 FPXX ABI
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- Cc: "macro\ at codesourcery dot com" <macro at codesourcery dot com>, "Joseph Myers \(joseph\ at codesourcery dot com\)" <joseph at codesourcery dot com>, "binutils\ at sourceware dot org" <binutils at sourceware dot org>, Rich Fuhler <Rich dot Fuhler at imgtec dot com>
- Date: Thu, 10 Apr 2014 13:49:02 +0100
- Subject: Re: [PATCH 1/2] Add support for O32 FPXX ABI
- Authentication-results: sourceware.org; auth=none
- References: <6D39441BF12EF246A7ABCE6654B023534DAAAB at LEMAIL01 dot le dot imgtec dot org> <87a9c0xkje dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534DC37D at LEMAIL01 dot le dot imgtec dot org> <87ha655s3i dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <6D39441BF12EF246A7ABCE6654B023534DC8CF at LEMAIL01 dot le dot imgtec dot org> <871tx9z35k dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <6D39441BF12EF246A7ABCE6654B023534DFC40 at LEMAIL01 dot le dot imgtec dot org> <878urd37t7 dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <6D39441BF12EF246A7ABCE6654B023534DFD9B at LEMAIL01 dot le dot imgtec dot org>
Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
> Richard Sandiford <firstname.lastname@example.org> writes:
>> Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
>> > Richard Sandiford <email@example.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
>> > section then copy it to the MIPS attribute section (or if already
>> > 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
>> > The explicit .gnu_attribute and .mips_attribute would just set
>> > 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
> 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'.
The "gnu" doesn't mean that the tools that produced it were GNU tools.
It just means that the extension was originally defined as a GNU one,
regardless of how widely it ends up being used. And I think "gnu" was
used not for marketing reasons but to avoid name clashes with anything
else that comes along.
Having LLVM support .gnu_attribute seems no stranger than having it
support the GNU DWARF extensions (which it does) or having lld generate
I just don't see any technical merits to this. You didn't list it
explicitly, but I assume we'd have a .mips_attribute directive to go
alongside .gnu_attribute. And like you say, .mips_attribute would need
to generate a .gnu_attributes section for compatiblity with existing
tools and .gnu_attribute would need to generate a .mips_attributes
section for compliance with the new ABI. If any tool (including LLVM)
fails to emit .gnu_attributes, it's risking silent link incompatibilities
for the existing FP attribute. So in the safe case, all we'd really end
up with is two sections with identical contents. You could say that the
use of .gnu_attributes would be deprecated on MIPS, but from a QoI
perspective we'd want to continue to process old objects and (as far
as possible) continue to generate objects that are compatible with old
linkers. Once we have the dual sections working, in practice the
.gnu_attributes side would never go away.
So I don't think you're going to convince me that this is a good idea.
But at the end of the day, it's a decision that's being made for branding
rather than technical reasons and you guys obviously control the ABI for