Re: Building newlib for Cortex-M with LLVM

[Emmanuel Blot <eblot dot ml at gmail dot com>]

Hi,

It seems there are still a couple of fixes (from  Jonathan Roelofs
<jonathan@codesourcery.com>) that could be merged into the newlib
source tree so that it is possible to build newlib with clang/LLVM on
ARM, at least:

   - fixes in arm/strcpy.c where STR type and condition are inverted,
since clang sticks with ARM documentation:
http://infocenter.arm.com/help/topic/com.arm.doc.dui0489c/CIHGCADB.html,
that is “op{type}{cond}” where newlib implementation uses
“op{cond}{type}”.

The permutation triggers an invalid instruction fatal error in clang
integrated assembler

Moreover, there is an issue with libnosys building, as HAVE_ELF ends
up being undefined. I’m not sure about my own fix, but it seems that
accepting “-eabi” as a valid ELF target fixes the issue, i.e.:

index 1d4846b..6f17827 100644
--- a/libgloss/libnosys/configure.in
+++ b/libgloss/libnosys/configure.in
@@ -88,7 +88,7 @@ esac

 dnl Make sure we know if elf format used
 case "${target}" in
-  *-*-elf)
+  *-*-elf | *-*-eabi*)
         AC_DEFINE(HAVE_ELF)

         AC_CACHE_CHECK([for .previous assembler directive],


Finally, I’d like to known whether there is a proper way to disable
Linux-specific code altogether when building libgloss, to target bare
metal newlib builds. I hacked the libgloss/arm Makefile to achieve
this, but I guess there is a proper way to achieve the same result:

diff --git a/libgloss/arm/Makefile.in b/libgloss/arm/Makefile.in
index 3f87dea..96b82f6 100644
--- a/libgloss/arm/Makefile.in
+++ b/libgloss/arm/Makefile.in
@@ -100,7 +100,7 @@ INCLUDES += `if [ -d ${objroot}/newlib ]; then
echo -I$(srcroot)/newlib/libc/mac
 # build a test program for each target board. Just trying to get
 # it to link is a good test, so we ignore all the errors for now.
 #
-all: ${CRT0} ${LINUX_CRT0} ${LINUX_BSP} ${REDBOOT_CRT0}
${REDBOOT_OBJS} ${RDPMON_CRT0} ${RDPMON_BSP} ${RDIMON_CRT0}
${RDIMON_BSP}
+all: ${CRT0}
        @rootpre=`pwd`/; export rootpre; \
        srcrootpre=`cd $(srcdir); pwd`/; export srcrootpre; \
        for dir in .. ${SUBDIRS}; do \
@@ -177,7 +177,7 @@ distclean maintainer-clean realclean: clean
        rm -f Makefile config.status *~

 .PHONY: install info install-info clean-info
-install: ${CRT0_INSTALL} ${LINUX_INSTALL} ${REDBOOT_INSTALL}
${RDPMON_INSTALL} ${RDIMON_INSTALL} ${IQ80310_INSTALL}  ${PID_INSTALL}
${NANO_INSTALL}
+install: ${CRT0_INSTALL} ${NANO_INSTALL}
        @rootpre=`pwd`/; export rootpre; \
        srcrootpre=`cd $(srcdir); pwd`/; export srcrootpre; \
        for dir in .. ${SUBDIRS}; do \


Thanks,
Manu.


On Thu, Nov 12, 2015 at 4:58 PM, Jonathan Roelofs
<jonathan@codesourcery.com> wrote:
>
>
> On 11/11/15 4:16 PM, 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.
>
> snip
>>
>>
>> * 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
>
>
> This one is very unlikely to get fixed in clang. I ran into this same exact
> thing about a year ago... now I feel bad for not upstreaming the patches for
> it.  Attached is what I was able to dig out of version control, HTH.
>
>
> Jon
>
>
>>
>> Any feedback or comment on my investigation are welcome. I am quite
>> happy to try few things.
>>
>> Thanks,
>>
>> ---
>> Olivier MARTIN
>> http://labapart.com - Lab A Part
>
>
> --
> Jon Roelofs
> jonathan@codesourcery.com
> CodeSourcery / Mentor Embedded