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

struct mips_flags_0
{
uint32_t version;    /* mips_flags_0: version==0.  */
uint32_t e_flags2;
};

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.

Regards,
Matthew