[oe] softfloat calling conventions in ARM gcc 4.x

[Michael K. Edwards]

I've been using crosstool as a framework for building ARM linux
cross-compile toolchains with a fair amount of success, but there are
certainly some tricks and traps.  OpenEmbedded toolchains have
impressed some of the crosstool participants, and I'm starting to look
at them now.  I'm pleased to see that EABI support is stabilizing, and
expect to use it for most ARM builds in the future.  However, I
anticipate needing to run existing OABI binaries on the system, and
some of those have been built with soft FP.

It seems that there have long been some patches needed for soft-float
toolchains, which have not been applied to GCC upstream for good and
sufficient reason.  The patch at
http://www.handhelds.org/hypermail/oe-commits/54/5483.html contains
one variant of these changes for a gcc 4.2 snapshot.  In particular,
it alters the portion of t-linux containing the list of libgcc
functions taken from lib1funcs.asm to the following:

++LIB1ASMFUNCS = _udivsi3 _divsi3 _umodsi3 _modsi3 _dvmd_lnx \
++ _negdf2 _addsubdf3 _muldivdf3 _cmpdf2 _unorddf2 _fixdfsi _fixunsdfsi \
++ _truncdfsf2 _negsf2 _addsubsf3 _muldivsf3 _cmpsf2 _unordsf2 \
++ _fixsfsi _fixunssfsi _floatdidf _floatdisf

If one were to follow the example of t-linux-eabi, taking the list in
t-arm-elf and replacing _dvmd_tls with _dvmd_lnx (which raises SIGFPE
on divide-by-zero), one would get:

+LIB1ASMFUNCS = _udivsi3 _divsi3 _umodsi3 _modsi3 _dvmd_lnx _bb_init_func \
+       _call_via_rX _interwork_call_via_rX \
+       _lshrdi3 _ashrdi3 _ashldi3 \
+       _negdf2 _addsubdf3 _muldivdf3 _cmpdf2 _unorddf2 _fixdfsi _fixunsdfsi \
+       _truncdfsf2 _negsf2 _addsubsf3 _muldivsf3 _cmpsf2 _unordsf2 \
+       _fixsfsi _fixunssfsi _floatdidf _floatdisf

Presumably _lshrdi3 _ashrdi3 _ashldi3 are suitable for t-linux if the
others are.  Do you know whether the _bb_init_func, _call_via_rX, and
_interwork_call_via_rX functions are for some reason inappropriate for
OABI on armv[45]t?  Do you know whether the floating point functions
conditionally compile correctly for FPA or VFP calling conventions?

I plan to actually test these things and report back to the
OpenEmbedded, crossgcc, and linux-arm-toolchain lists.  But even
thorough testing is no substitute for a description of the theory of
operations; so any comments from people who know what they are doing
are welcome.

Cheers,
- Michael