> > 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
