This is the mail archive of the
mailing list for the binutils project.
RE: [PATCH 1/2] Add support for O32 FPXX ABI
- From: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- To: Richard Sandiford <rdsandiford at googlemail 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: Fri, 11 Apr 2014 07:13:55 +0000
- 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> <87fvll1ha9 dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com>
Richard Sandiford <firstname.lastname@example.org> writes:
> Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
> > Richard Sandiford <email@example.com> writes:
> >> 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'.
> 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
> PT_GNU_STACK headers.
I mostly agree here with the one difference that those GNU features are
> 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.
Indeed. Only the loadable section would have benefitted from the change.
> 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 your architecture.
I don't think anyone at Imagination will try to force an ABI decision
but as we look at formalising and recording the de-facto ABI used in the
GNU tools then there are likely to be a few things to talk through.
Independently of discussing MIPS vs GNU attributes I have been working
on implementing the parsing of attribute sections in glibc by stealing
code from BFD. I had not quite appreciated the complexity of the attribute
section and the fact it has strings and uleb128 encoded values means
everything is unaligned which is a bit frustrating. In retrospect I'm
thinking the flexibility of the attribute section is not necessary for
what we need and the alternative proposal of a versioned structure seems
more desirable at this point. I'm wary of having to implement/maintain
this in several linkers and loaders (linux/*bsd etc) but the simpler
structure alternative would ease this.
Any objection to changing direction on the loadable section and
introducing a new section at link time to contain a simple structure?
Assuming that seems OK then I'd propose starting with:
uint32_t version; /* mips_flags_0: version==0. */
Any opinion on whether this should take a copy of the normal e_flags
field too, and/or whether the new flags field should follow the name
of the e_flags field or not? I can see pros and cons for including a
copy of the e_flags field. It may be better to uncompress the flags
so that there is a simple entry for architecture etc. This doesn't
really need dealing with right now though.