From: Emmanuel Blot <eblot.ml@gmail.com>
To: newlib@sourceware.org
Subject: Re: Building newlib for Cortex-M with LLVM
Date: Thu, 15 Jun 2017 10:52:00 -0000 [thread overview]
Message-ID: <CAKJJEPx=mY64q0CqeHbVEGJaD8V2W8czMr5jVMdY_mXpVZQttQ@mail.gmail.com> (raw)
In-Reply-To: <5644B73E.1070802@codesourcery.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
prev parent reply other threads:[~2017-06-15 10:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-12 4:11 Olivier MARTIN
2015-11-12 11:17 ` Marcus Shawcroft
2015-11-12 12:39 ` Clemens Ladisch
2015-11-12 13:46 ` Olivier MARTIN
2015-11-12 14:22 ` Richard Earnshaw
2015-11-12 15:33 ` Olivier MARTIN
2015-11-12 15:50 ` Richard Earnshaw
2015-11-12 15:56 ` Olivier MARTIN
2015-11-12 15:59 ` Richard Earnshaw
2015-11-12 22:42 ` Jonathan Roelofs
2017-06-15 10:52 ` Emmanuel Blot [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAKJJEPx=mY64q0CqeHbVEGJaD8V2W8czMr5jVMdY_mXpVZQttQ@mail.gmail.com' \
--to=eblot.ml@gmail.com \
--cc=newlib@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).