Re: [gccsdk] asasm always claims to want hardware FP

On 06/23/2016 04:23 PM, Dave Higton wrote:
> There seems to be a problem with asasm of gcc 4.7.4. See the ROOL
> Community Support forum, topic "DeskLib and GCC 4.7.4" for details.
>
> In short, even the most trivial code assembled with asasm 2.01 r6919
> results in an ELF file that claims to use hardware FP (even though
> there is no FP in the code at all), and I haven't found it possible
> to influence this. r5871 accepted a command line option -soft-float
> that r6919 doesn't. r6919 accepts an option -fpu= but none of the
> 53 options available causes it to change its behaviour.

It's roughly two years ago I last contributed to AsAsm so I'm not 100%
sure any more about all following details.

The idea of AsAsm is to be compatible with ROOL's ObjAsm (incl. command
line options) and on top of that not only support AOF but also the ELF
file format. That also means following what ARM adds as functionality
to their assembler. So that's why at some point the -cpu/-fpu options
appeared and the -soft-float one got dropped.

It is (was) work in progress. For how things are to be implemented in
the ELF file format I followed what ARM defined in their public EABI/ELF
documents. Those -cpu/-fpu options are, partly, defining the EABI
flavour needs to be written, including the EABI object attributes. That
hasn't happened, hence, I believe we're now writing a pre-EABI ELF
format which is rightfully considered hard-float by the binutils linker.

By just defining ELF_EABI at build time you fall by default in the
soft-float case (but also claim to be EABI compliant which I'm not sure
if that's really true) but the real way forward is to write proper EABI
object attributes based on command line options and attributes specified
in the assembler source.

Personally I find it pity that I ran out of steam doing all this,
hopefully someone can pick up this project. I'm happy to give advice if
wanted. If the RISC OS developer community wants to leverage on the
existing free/open compiler/linker tools (gcc, llvm ecosystem, binutils,
etc.) for RISC OS, as OS, development, this realistic rules out AOF and
only leaves ELF file format. And then AsAsm is important piece in that
puzzle. Or alternatively have to teach non-free/open ObjAsm to output
ELF + DWARF and then also support ELF fully in the link linker...

John.


_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK