Re: EP9312 gcc: undefined reference to __divdf3

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

On Thu, 2004-07-01 at 19:26, Vladimir Ivanov wrote:
> On Thu, 1 Jul 2004, Richard Earnshaw wrote:
> 
> > On Thu, 2004-07-01 at 11:53, Paul Brook wrote:
> >
> > > 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.
> >
> > I agree.  In fact, it would be extremely useful if somebody could write
> > a co-processor supplement to the AAPCS for Maverick.  Such a document
> > would have to cover the following sections of the main document[1]:
> >
> >         - A statement equivalent to section 5.1.1.1 concerning Maverick
> >         registers.
> >
> >         - A section equivalent to 6.1 (and all its subsections)
> >         documenting when results are not returned in core registers and
> >         which arguments to function calls should be considered for
> >         passing in registers other than core registers.
> >
> > Ideally the supplement should also document the compatibility of the
> > variant with the various other variants that exist, equivalent to those
> > statements in section 6.3.
> >
> > It's not a big task, probably only a couple of sides of A4 based on the
> > equivalent information for the VFP co-processor.
> 
> We can do this. Do you have any template for this document?
> Contact me in case we can help.

Not as a standalone document, the VFP is the only co-processor we've
produced this information for so far and that's recored as part of the
AAPCS document itself.  However, I've tried to keep the material
relating to the VFP as distinct sections even then.

So your best starting point would be to look at the sections I've
outlined in the AAPCS and to replicate them with appropriate changes
made for the Maverick.

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

> 
> > Note that the existing calling convention *could* be written up in this
> > way, but I'm not sure that would really want to adopt this calling
> > convention -- it's very inefficient if you have floating point registers
> > to keep moving the values back to core registers, and there's no merit
> > of compatibility with the soft-call standard when the result values can
> > come back in a non-standard register.
> 
> I agree that it is quite strange, but it is adopted from FPA and is the
> de-facto ABI for GCC-3.4. If the various ABI variants for VFP are already
> implemented in GCC mainline, porting them to MaverickCrunch seems
> reasonable task.

The FPA calling model as implemented by GCC goes back into pre-history
and was implemented that way because that's what the ABI of RISC iX used
(the first ARM port of GCC was to RISC iX).  History, however, suggests
that was a poor design choice and we don't want to perpetuate that
mistake any longer than necessary.
 
There's no support for using VFP registers for argument passing in GCC
yet, though that's certainly on the to-do list somewhere.  And yes, if
the rules are similar enough it shouldn't be a major task to support
Maverick as well.

R.