This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: EP9312 gcc: undefined reference to __divdf3
- From: Richard Earnshaw <rearnsha at gcc dot gnu dot org>
- To: Paul Brook <paul at codesourcery dot com>
- Cc: gcc at gcc dot gnu dot org, Wouter van Heyst <wouter at vidicode dot org>, Vladimir Ivanov <vladitx at nucleusys dot com>
- Date: Thu, 01 Jul 2004 12:55:50 +0100
- Subject: Re: EP9312 gcc: undefined reference to __divdf3
- Organization: GNU
- References: <20040629092214.GA9700@larstiq.dyndns.org> <1088588729.4991.21.camel@pc960.cambridge.arm.com> <20040630154627.GI1209@larstiq.dyndns.org> <200407011153.45361.paul@codesourcery.com>
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.
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.
R.