This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: Problems with Newlib built with Clang for Cortex-M
On 02/11/2018 13:12, Jangseop Shin wrote:
> 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.
>
__VFP_FP__ defines the /format/ of the floating point numbers in use.
It does not indicate the presence or absence of VFP instructions. So
this is another clang bug.
R.
> ==== 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
>>