From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10448 invoked by alias); 15 Jun 2017 10:52:50 -0000 Mailing-List: contact newlib-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: newlib-owner@sourceware.org Received: (qmail 10402 invoked by uid 89); 15 Jun 2017 10:52:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy=hacked X-HELO: mail-lf0-f65.google.com Received: from mail-lf0-f65.google.com (HELO mail-lf0-f65.google.com) (209.85.215.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 15 Jun 2017 10:52:47 +0000 Received: by mail-lf0-f65.google.com with SMTP id u62so1025638lfg.0 for ; Thu, 15 Jun 2017 03:52:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=hQMFMY0IoHeTfQEOXuEdJlSaI6RkyV1y6LZFgNYz2Y4=; b=Er2Kzxrz0DXpa51/bpzjVJNOGVM5h8eHZAJBaigfv0x/DPlrS6pK9046sArsqWf55y eLij/Eyc0Plicg3Yh6RhKyOC1xxItH7Mt4k/O26En0ltVAlae7b6BuEHzf70g+M+dTHs lj9YMKHX41Yn13ldy2lYYZp+U0aAaG1ZqKdyh0jPp2Rfa3CIekzX+fwvJA5Vyz4N1BFq mw6vgZudvx9iH77Fmen6fhfUFo63RLPunmRSRBxhZIgjPbfyZQt5Hed70jTl1MJK73Dd r8pW4XBTxWa73HHJc4GDyzck2sqf4owe3mrjwB5H1J0eIlP5Q6zk/rJ5TA36UVrgel9U VUhw== X-Gm-Message-State: AKS2vOyhqDRQ2iRSzPg9OjBoOFZUmJ7ZAxxFzyUCSIqkOsmMUzQpSPS3 vDKMx0Ey3Sb5VLci4S66oKbxyzeiAvyZ X-Received: by 10.46.9.146 with SMTP id 140mr1527553ljj.42.1497523969838; Thu, 15 Jun 2017 03:52:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.204.69 with HTTP; Thu, 15 Jun 2017 03:52:49 -0700 (PDT) In-Reply-To: <5644B73E.1070802@codesourcery.com> References: <8473a04381ff7d35caa7ea1e8eb08772@labapart.com> <5644B73E.1070802@codesourcery.com> From: Emmanuel Blot Date: Thu, 15 Jun 2017 10:52:00 -0000 Message-ID: Subject: Re: Building newlib for Cortex-M with LLVM To: newlib@sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017/txt/msg00431.txt.bz2 Hi, It seems there are still a couple of fixes (from Jonathan Roelofs ) 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 =E2=80=9Cop{type}{cond}=E2=80=9D where newlib implementation uses =E2=80=9Cop{cond}{type}=E2=80=9D. 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=E2=80=99m not sure about my own fix, but it seems that accepting =E2=80=9C-eabi=E2=80=9D 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=E2=80=99d 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 +=3D `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=3D`pwd`/; export rootpre; \ srcrootpre=3D`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=3D`pwd`/; export rootpre; \ srcrootpre=3D`cd $(srcdir); pwd`/; export srcrootpre; \ for dir in .. ${SUBDIRS}; do \ Thanks, Manu. On Thu, Nov 12, 2015 at 4:58 PM, Jonathan Roelofs 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=3D25495 > > > This one is very unlikely to get fixed in clang. I ran into this same exa= ct > 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