Re: Building newlib for Cortex-M with LLVM

[Richard Earnshaw <Richard dot Earnshaw at foss dot arm dot com>]

Just as a general principle, it would be much easier to track the
multiple issues you have here if they were reported as one issue per
email; it's going to be far too easy to miss individual problems if
they're all in one thread.

On 11/11/15 23:16, Olivier MARTIN wrote:
> Hello all,
> recently I found a warning generated by Clang while building my project
> that is based on Newlib (see
> https://sourceware.org/ml/newlib/2015/msg00714.html).
> 
> I was curious... and I was wondering whether I could build newlib with
> Clang.
> The answer is probably the one you were expected, no!
> I am not really familiar with newlib build configuration, I went for the
> basic steps I found on the Internet:
> 

It looks like you are (amongst) the first to try this...

> mkdir build-newlib-llvm
> cd build-newlib-llvm
> export
> AS_FOR_TARGET=/home/olivier/Toolchains/gcc-arm-none-eabi-4_9-2014q4/bin/arm-none-eabi-as
> 
> export CC_FOR_TARGET=/usr/bin/clang-3.6
> export CFLAGS_FOR_TARGET="-target arm-none-eabi"
> export PATH=/home/olivier/Toolchains/gcc-arm-none-eabi-4_9-2014q4/bin:$PATH
> ../configure --target=arm-none-eabi
> --prefix=/home/olivier/Toolchains/gcc-arm-none-eabi-4_9-2014q4
> --disable-newlib-supplied-syscalls --with-cpu=armv7m --with-mode=thumb
> --enable-interwork
> make all
> 
> There are two issues I manage to isolate.
> 
> * The first one can be solved. The space in the call of CONCAT2(a, b) by
> CONCAT() is propagated into the subsequent calls. It means when the
> strings 'a' and 'b' are concatenated, the space is inserted between both
> strings - which is not the expected behaviour.
> 
> The fix would be:
> 
> --- a/newlib/libc/machine/arm/setjmp.S
> +++ b/newlib/libc/machine/arm/setjmp.S
> @@ -3,7 +3,7 @@
>     Nick Clifton, Cygnus Solutions, 13 June 1997.  */
> 
>  /* ANSI concatenation macros.  */
> -#define CONCAT(a, b)  CONCAT2(a, b)
> +#define CONCAT(a, b)  CONCAT2(a,b)
> 

Already discussed in a sub-thread.

> * The second issue is what I believe to be a Clang issue. Clang does not
> support when macros are defined into inline assembly and used later on.
> Assembly macros are quite used in the ARM string functions (eg:
> 'RETURN', 'optpld' macros).
> I raised a Clang bug for this one:
> https://llvm.org/bugs/show_bug.cgi?id=25495
> 

I'm not against moving these large 'implemented in assembly' routines
out into separate .S files.  Marcus is already working on strlen.S as I
write this (watch this list, I expect some patches in the next few
days).  If you want to copy that approach to get rid of the strcpy
inline assembler version, then I'd be happy to consider patches in this
area.

> I had other issues but they might come from the fact I have not
> correctly configured newlib for Cortex-M...
> 
> For instance, the following errors:
> - libgloss/arm/linux-crt0.c:34:2: error: non-ASM statement in naked
> function is not supported
>         register int *sp asm("sp");

This one's going to be tricky.  It might be easier to rework the entire
file to be a real .S file, but I haven't looked at it in detail to see
how it interacts with the make system.

> - libgloss/libnosys/chown.c
>     <inline asm>:1:8: error: unsupported directive '.stabs'
>     .stabs "_chown is not implemented and will always fail",30,0,0,0
> - '.syntax divided' is not supported - it is used in
> newlib/libc/machine/arm/*.S

This just looks like your build system hasn't defined HAVE_GNU_LD and so
you're picking up the wrong definition of stub_warning from
libc/sys/linux/libc-symbols.h.

> 
> Note: I cannot see the armv7m/thumb/interwork flags to be propagated
> into the build commands.
> 
> Any feedback or comment on my investigation are welcome. I am quite
> happy to try few things.
> 

R.