[RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking

[Matthew Fortune]

> > Sorry, forgot about that.  In that case maybe program headers would be
> > best, like you say.  I.e. we could use a combination of GNU attributes
> > and a new program header, with the program header hopefully being more
> > general than for just this case.  I suppose this comes back to the
> > thread from binutils@ last year about how to manage the dwindling
> > number of free flags:
> >
> >     https://www.sourceware.org/ml/binutils/2013-09/msg00039.html
> >  to https://www.sourceware.org/ml/binutils/2013-09/msg00099.html
> >

There are a couple of issues to resolve in order to use gnu attributes to record FP requirements at the module level. As it currently stands gnu attributes are controlled via the .gnu_attribute directive and these are emitted explicitly by the compiler. I think it is important that a more meaningful directive is available but it will need to interact nicely with the .gnu_attribute as well.

The first problem is that there will be new ways to influence whether a gnu attribute is emitted or not. i.e. the command line options -mfp32, -mfpxx, -mfp64 will infer the relevant attribute Tag_GNU_MIPS_ABI_FP and if the .module directive is present then that would override it. Will there be any problems with a new ways to generate a gnu attribute?

The second problem is that in order to support relaxing a mode requirement then any up-front directive/command line option that sets a specific fp32/fp64 requirement needs to be updated to fpxx. With gnu attributes this would mean updating an existing Tag_GNU_MIPS_ABI_FP setting to be modeless.

I don't think any other port does this kind of thing in binutils but that doesn't mean we can't I guess.

Regards,
Matthew