From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6506 invoked by alias); 12 Nov 2015 15:56:09 -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 6490 invoked by uid 89); 12 Nov 2015 15:56:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 12 Nov 2015 15:56:08 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A8A0E49; Thu, 12 Nov 2015 07:55:53 -0800 (PST) Received: from e105689-lin.cambridge.arm.com (e105689-lin.cambridge.arm.com [10.2.207.32]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 18FBA3F50D; Thu, 12 Nov 2015 07:56:05 -0800 (PST) Subject: Re: Building newlib for Cortex-M with LLVM To: Olivier MARTIN , newlib@sourceware.org References: <8473a04381ff7d35caa7ea1e8eb08772@labapart.com> From: Richard Earnshaw X-Enigmail-Draft-Status: N1110 Message-ID: <5644B694.8070801@foss.arm.com> Date: Thu, 12 Nov 2015 15:59:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <8473a04381ff7d35caa7ea1e8eb08772@labapart.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2015/txt/msg00813.txt.bz2 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 > :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.