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

[Jangseop Shin <jeffy861009 at gmail dot com>]

On Wed, Oct 31, 2018 at 10:54 PM Richard Earnshaw (lists) <
Richard.Earnshaw@arm.com> wrote:

> 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.
>
>
Sorry if I sounded a bit rude. So about the compile errors:

- I filed a bug to Clang about GNU assembler syntax.

- The error message for HAVE_GNU_LD is this:

<inline asm>:1:8: error: unsupported directive '.stabs'
.stabs "_chown is not implemented and will always fail",30,0,0,0
       ^
<inline asm>:2:8: error: unsupported directive '.stabs'
.stabs "_chown",1,0,0,0
       ^
2 errors generated.

Clang assembler does not understand .stabs directive and they do not seem
to plan to support it (https://sourceforge.net/p/libjpeg-turbo/bugs/72/)

However, newlib/libgloss/libnosys/configure.in seem to define HAVE_GNU_LD
regardless of whether clang or gcc is used.

- ldrb    r2, [r3], #1

Clang does not give error for ldrb.w r2, [r3, #1].
It is a little confusing because "A7.7.45 LDRB(immediate)" section of the
ARM7-m architecture manual shows that  .W suffix is applied to T2 encoding
but not to T3 encoding.
However "A7.2 Standard assembler syntax fields" suggests that .W suffix is
used to force the assembler to select 32-bit encoding. So I guess Clang
shouldn't really regard it as an error. I'll ask the Clang guys for this
also.




> >
> > 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).
>
>
I'll look more into this.



> R.
>
> > Regards,
> > Jangseop
> >
>
>