Matthew Fortune <matthew.fort...@imgtec.com> writes: >> > 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?
I think we should just give an error if any .gnu_attributes are inconsistent with the module-level setting (whether that comes from .module or command-line flags). > 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. Not sure what you mean here, sorry. Thanks, Richard
