Re: EP9312 gcc: undefined reference to __divdf3

[Richard Earnshaw <rearnsha at gcc dot gnu dot org>]

On Wed, 2004-06-30 at 16:46, Wouter van Heyst wrote:
> > 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. 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.
> 
> 1. http://gcc.gnu.org/ml/gcc-patches/2003-12/msg00642.html
> 

Substantially yes -- note that that email was a design sketch, it may
not be exactly what was implemented in GCC, but it does give the right
split of the various permutations.

You should also look at the various EABI specifications, 

	http://www.arm.com/products/DevTools/ABI.html

specifically, at these two:

	http://www.arm.com/products/DevTools/abi/aapcs.pdf
	http://www.arm.com/products/DevTools/abi/rtabi.pdf

It's not explicit in that document, but the intention is that,
regardless of the calling convention in use for 'user' code, all support
functions should be implemented using the base-standard calling
convention (this provides for a modicum of Thumb interworking).  That's
substantially variants 8 and 9 in the email I posted previously.

R.