Re: EP9312 gcc: undefined reference to __divdf3

[Paul Brook <paul at codesourcery dot com>]

> > The problem is that the FPU on this chip does not have a floating point
> > divide instruction, so we need to provide one in software.  The library
> > function that we have (in config/arm/ieee754-df.c) returns values in
> > integer registers, but in the configuration you have the compiler would
> > expect it to be returned in an FP register; so at this point in time
> > there is no benefit to be gained from making it call the library
> > function directly.
>
> So that's close to variant 8 (-mfpu=maverick -mfloat-abi=soft+fp) from [1],
> except several of the hardware instructions will have to be done in
> software too.

Yes, variant 8 should 'just work', except that it isn't implemented in the 
compiler :)

To get full hardware float (variant 9) you need to modify the support routines 
for unimplemented instructions (eg. div) to return values in hardware 
registers.

N.B. The current maverick ABI is based on the legacy fpa ABI, and passes 
floating point values in integer registers.
I think someone mentioned they were changing the ABI anyway. If so it's 
probably worth fixing this to pass arguments in fp regs at the same time.

> Am I right that this form of variant 8 will be ABI 
> compatible with other -mfloat-abi=soft+fp and -mfloat-abi=soft binaries,
> but also have hardware support in function bodies for the fpu of my
> choice? If so, that would be the optimal situation.

There are two issues that determine binary compatability: The ABI used for 
passing/returning floating point function arguments (-mfloat-abi=), and the 
floating point format used (-mfpu=).

The maverick coprocessor uses a different floating point format the fpa 
coprocessor (the linux default), so is never going to be comapatible.

For a given floating point format, the soft and soft+fp options use the same 
ABI.

In general the different floating point format are not binary compatible with 
each other. While all they all use IEEE format, they use differing byte 
endianness. Thus variant 8 is not binary compatible with variants 5 or 6.

Paul

> 1. http://gcc.gnu.org/ml/gcc-patches/2003-12/msg00642.html