Re: Problems with Newlib built with Clang for Cortex-M

On 31/10/2018 12:40, Jangseop Shin wrote:
> Hello, I'm doing a project using RIOT-OS on Cortex-M.
> I would like to instrument the code that are linked into the final binary
> using LLVM. Since RIOT-OS uses newlib, I tried to compile newlib using
> Clang.
> 
> I used the GNU ARM Embedded Toolchain (gcc-arm-none-eabi-7-2018-q2-update)
> with 20180831 snapshot of newlib, clang-7.0.0, and RIOT-OS 2018.10 branch.
> 
> First there were a few compile errors.
> (libgloss/arm/linux-syscalls0.S - GLOBAL => global  on line 105
> liggloss/libnosys/warning.h -  define stub_warning as null
> newlib/libc/machine/arm/strlen-thumb2-Os.S) - ldrb.w => ldrb (line 48)
> 
> (The fact that these are all quite old files gives me a feeling that newlib
> is not really serious about supporting Clang??)

On the contrary, the problem is that appears that clang is just not
serious about correctly implementing the GNU assembler syntax.

.GLOBAL: directive keywords are case independent - .global .Global and
.GLOBAL should all work exactly the same (as would .gLobal, for that
matter).
stub_warning: is wrapped inside of HAVE_GNU_LD, why is that defined if
you're using clang?  However, you don't really say what the error is, so
it's hard to really know what the problem is.
ldrb.w: this is a legal mnemonic, if clang doesn't accept it, then it
needs fixing.

> 
> After I fixed the errors I could get the library file.
> But when I tried to run the application on Cortex-M3 (Arduino-due board),
> some of the app crash or produce incorrect results.
> One of the bug I suspect is with newlib/libc/stdlib/dtoa.c  file, since it
> makes my system halt when I try to print floating point number.
> (I looked up the internet and added -fno-strict-aliasing flag to cflags
> with no luck.)
> When I replaced that specific object file in the libc library with the
> gcc-compiled one, the app does not crash. (However, it still produces
> incorrect results)
> Replacing libm with the gcc-compiled version corrected the results to some
> extent, but the floating point numbers are randomly printed with wrong sign.
> 
> I would very much appreciate any help on this issue.
> 

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).

R.

> Regards,
> Jangseop
>