Problems with Newlib built with Clang for Cortex-M

[Jangseop Shin]

The problem was that Clang does not define __VFP_FP__ while
arm-none-eabi-gcc does. This caused endianness problem in the following
code. The comments in the code says that __VFP_FP__ is defined even with
soft-float, but Clang seems to define it only when VFP is actually used.

==== newlib/libc/include/machine/ieeefp.h ========

#if (defined(__arm__) || defined(__thumb__)) && !defined(__MAVERICK__)
/* ARM traditionally used big-endian words; and within those words the byte
ordering was big or little endian depending upon the target. Modern
floating-point formats are naturally ordered; in this case  __VFP_FP__ will
be defined, even if soft-float.  */
#ifdef __VFP_FP__
# ifdef __ARMEL__
#  define __IEEE_LITTLE_ENDIAN
# else
#  define __IEEE_BIG_ENDIAN
# endif
# if __ARM_FP & 0x8
#  define __OBSOLETE_MATH_DEFAULT 0
# endif
#else
# define __IEEE_BIG_ENDIAN
# ifdef __ARMEL__
#  define __IEEE_BYTES_LITTLE_ENDIAN
# endif
#endif
#endif

====================================


On Wed, Oct 31, 2018 at 11:40 PM Keith Packard <keithp@keithp.com> wrote:

> "Richard Earnshaw (lists)" <Richard.Earnshaw@arm.com> writes:
>
> > These sound like your stack is not correctly aligned: a common symptom
> > of failing to do this is that calls to the printf family fail when
> > 64-bit sized items (like double) are passed.  The EABI requires 64-bit
> > alignment at all function boundaries (and 32-bit alignment at all other
> > times).
>
> I ran into this with one embedded platform that wasn't aligning the
> initial thread stack on 64-bit boundaries. The compiler was carefully
> counting pushes/pops for non-varargs functions, but varargs was
> computing the rounding and because the initial stack point was
> mis-aligned, everything "worked" except for 64-bit (double) values to
> printf which got fetched from the wrong address.
>
> --
> -keith
>