Building newlib for Cortex-M with LLVM

Building newlib for Cortex-M with LLVM

[Olivier MARTIN]

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:

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)

* 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 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");
- 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

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.

Thanks,

---
Olivier MARTIN
http://labapart.com - Lab A Part

Re: Building newlib for Cortex-M with LLVM

[Marcus Shawcroft]

On 11 November 2015 at 23:16, Olivier MARTIN <olivier@labapart.com> wrote:

> * 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)

Have you looked at the C standard on this issue? I wonder which
compiler, gcc or clang is not compliant with the standard.

Cheers
/Marcus

Re: Building newlib for Cortex-M with LLVM

[Clemens Ladisch]

Marcus Shawcroft wrote:
> On 11 November 2015 at 23:16, Olivier MARTIN <olivier@labapart.com> wrote:
>> * 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:
>>
>> -#define CONCAT(a, b)  CONCAT2(a, b)
>> +#define CONCAT(a, b)  CONCAT2(a,b)
>
> Have you looked at the C standard on this issue? I wonder which
> compiler, gcc or clang is not compliant with the standard.

6.10.3.3:
| If, in the replacement list of a function-like macro, a parameter is
| immediately preceded or followed by a ## preprocessing token, the
| parameter is replaced by the corresponding argument’s preprocessing
| token sequence; […]
| each instance of a ## preprocessing token in the replacement list
| (not from an argument) is deleted and the preceding preprocessing
| token is concatenated with the following preprocessing token.

Preprocessing tokens are defined in 6.4:
| preprocessing-token:
|   header-name
|   identifier
|   pp-number
|   character-constant
|   string-literal
|   punctuator
|   each non-white-space character that cannot be one of the above
| […]
| White space may appear within a preprocessing token only as part of
| a header name or between the quotation characters in a character
| constant or string literal.

So clang is wrong.

It should be noted that example 4 (6.10.3.5 6) shows such a space:

  #define glue(a, b)  a ## b
  #define xglue(a, b) glue(a, b)


Regards,
Clemens

Re: Building newlib for Cortex-M with LLVM

[Olivier MARTIN]

On 12.11.2015 12:33, Clemens Ladisch wrote:
> Marcus Shawcroft wrote:
>> On 11 November 2015 at 23:16, Olivier MARTIN <olivier@labapart.com> 
>> wrote:
>>> * 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:
>>> 
>>> -#define CONCAT(a, b)  CONCAT2(a, b)
>>> +#define CONCAT(a, b)  CONCAT2(a,b)
>> 
>> Have you looked at the C standard on this issue? I wonder which
>> compiler, gcc or clang is not compliant with the standard.
> 
> 6.10.3.3:
> | If, in the replacement list of a function-like macro, a parameter is
> | immediately preceded or followed by a ## preprocessing token, the
> | parameter is replaced by the corresponding argument’s preprocessing
> | token sequence; […]
> | each instance of a ## preprocessing token in the replacement list
> | (not from an argument) is deleted and the preceding preprocessing
> | token is concatenated with the following preprocessing token.
> 
> Preprocessing tokens are defined in 6.4:
> | preprocessing-token:
> |   header-name
> |   identifier
> |   pp-number
> |   character-constant
> |   string-literal
> |   punctuator
> |   each non-white-space character that cannot be one of the above
> | […]
> | White space may appear within a preprocessing token only as part of
> | a header name or between the quotation characters in a character
> | constant or string literal.
> 
> So clang is wrong.
> 
> It should be noted that example 4 (6.10.3.5 6) shows such a space:
> 
>   #define glue(a, b)  a ## b
>   #define xglue(a, b) glue(a, b)
> 
> 
> Regards,
> Clemens

Thanks Clemens for looking into the C standards.
I did more investigation before raising a new Clang bug. And actually, 
the issue is more localized...
It only happen when the concatenation macro is invoked into an assembly 
macro (ie: '.macro') - otherwise clang behaves as expected.
Here is the clang issue: https://llvm.org/bugs/show_bug.cgi?id=25506

-- 
Olivier MARTIN
http://labapart.com - Lab A Part

Re: Building newlib for Cortex-M with LLVM

[Richard Earnshaw]

On 12/11/15 13:33, Olivier MARTIN wrote:
> On 12.11.2015 12:33, Clemens Ladisch wrote:
>> Marcus Shawcroft wrote:
>>> On 11 November 2015 at 23:16, Olivier MARTIN <olivier@labapart.com>
>>> wrote:
>>>> * 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:
>>>>
>>>> -#define CONCAT(a, b)  CONCAT2(a, b)
>>>> +#define CONCAT(a, b)  CONCAT2(a,b)
>>>
>>> Have you looked at the C standard on this issue? I wonder which
>>> compiler, gcc or clang is not compliant with the standard.
>>
>> 6.10.3.3:
>> | If, in the replacement list of a function-like macro, a parameter is
>> | immediately preceded or followed by a ## preprocessing token, the
>> | parameter is replaced by the corresponding argument’s preprocessing
>> | token sequence; […]
>> | each instance of a ## preprocessing token in the replacement list
>> | (not from an argument) is deleted and the preceding preprocessing
>> | token is concatenated with the following preprocessing token.
>>
>> Preprocessing tokens are defined in 6.4:
>> | preprocessing-token:
>> |   header-name
>> |   identifier
>> |   pp-number
>> |   character-constant
>> |   string-literal
>> |   punctuator
>> |   each non-white-space character that cannot be one of the above
>> | […]
>> | White space may appear within a preprocessing token only as part of
>> | a header name or between the quotation characters in a character
>> | constant or string literal.
>>
>> So clang is wrong.
>>
>> It should be noted that example 4 (6.10.3.5 6) shows such a space:
>>
>>   #define glue(a, b)  a ## b
>>   #define xglue(a, b) glue(a, b)
>>
>>
>> Regards,
>> Clemens
> 
> Thanks Clemens for looking into the C standards.
> I did more investigation before raising a new Clang bug. And actually,
> the issue is more localized...
> It only happen when the concatenation macro is invoked into an assembly
> macro (ie: '.macro') - otherwise clang behaves as expected.
> Here is the clang issue: https://llvm.org/bugs/show_bug.cgi?id=25506
> 

Not withstanding the clang macro-preprocessing issue, it looks as though
clang is also incorrectly defining __USER_LABEL_PREFIX__.  On an ELF
platform (such as ARM EABI) this should expand to nothing (there is no
prefix), and as such result from using CONCAT(a,b) should just be b.

R.

Re: Building newlib for Cortex-M with LLVM

[Olivier MARTIN]

On 12.11.2015 13:46, Richard Earnshaw wrote:
> On 12/11/15 13:33, Olivier MARTIN wrote:
>> On 12.11.2015 12:33, Clemens Ladisch wrote:
>>> Marcus Shawcroft wrote:
>>>> On 11 November 2015 at 23:16, Olivier MARTIN <olivier@labapart.com>
>>>> wrote:
>>>>> * 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:
>>>>> 
>>>>> -#define CONCAT(a, b)  CONCAT2(a, b)
>>>>> +#define CONCAT(a, b)  CONCAT2(a,b)
>>>> 
>>>> Have you looked at the C standard on this issue? I wonder which
>>>> compiler, gcc or clang is not compliant with the standard.
>>> 
>>> 6.10.3.3:
>>> | If, in the replacement list of a function-like macro, a parameter 
>>> is
>>> | immediately preceded or followed by a ## preprocessing token, the
>>> | parameter is replaced by the corresponding argument’s preprocessing
>>> | token sequence; […]
>>> | each instance of a ## preprocessing token in the replacement list
>>> | (not from an argument) is deleted and the preceding preprocessing
>>> | token is concatenated with the following preprocessing token.
>>> 
>>> Preprocessing tokens are defined in 6.4:
>>> | preprocessing-token:
>>> |   header-name
>>> |   identifier
>>> |   pp-number
>>> |   character-constant
>>> |   string-literal
>>> |   punctuator
>>> |   each non-white-space character that cannot be one of the above
>>> | […]
>>> | White space may appear within a preprocessing token only as part of
>>> | a header name or between the quotation characters in a character
>>> | constant or string literal.
>>> 
>>> So clang is wrong.
>>> 
>>> It should be noted that example 4 (6.10.3.5 6) shows such a space:
>>> 
>>>   #define glue(a, b)  a ## b
>>>   #define xglue(a, b) glue(a, b)
>>> 
>>> 
>>> Regards,
>>> Clemens
>> 
>> Thanks Clemens for looking into the C standards.
>> I did more investigation before raising a new Clang bug. And actually,
>> the issue is more localized...
>> It only happen when the concatenation macro is invoked into an 
>> assembly
>> macro (ie: '.macro') - otherwise clang behaves as expected.
>> Here is the clang issue: https://llvm.org/bugs/show_bug.cgi?id=25506
>> 
> 
> Not withstanding the clang macro-preprocessing issue, it looks as 
> though
> clang is also incorrectly defining __USER_LABEL_PREFIX__.  On an ELF
> platform (such as ARM EABI) this should expand to nothing (there is no
> prefix), and as such result from using CONCAT(a,b) should just be b.
> 
> R.

Your are correct Richard, I raised another clang defect 
https://llvm.org/bugs/show_bug.cgi?id=25508

--
Olivier
http://labapart.com - Lab A Part

Re: Building newlib for Cortex-M with LLVM

[Richard Earnshaw]

On 12/11/15 12:33, Clemens Ladisch wrote:
> Marcus Shawcroft wrote:
>> On 11 November 2015 at 23:16, Olivier MARTIN <olivier@labapart.com> wrote:
>>> * 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:
>>>
>>> -#define CONCAT(a, b)  CONCAT2(a, b)
>>> +#define CONCAT(a, b)  CONCAT2(a,b)
>>
>> Have you looked at the C standard on this issue? I wonder which
>> compiler, gcc or clang is not compliant with the standard.
> 
> 6.10.3.3:
> | If, in the replacement list of a function-like macro, a parameter is
> | immediately preceded or followed by a ## preprocessing token, the
> | parameter is replaced by the corresponding argument’s preprocessing
> | token sequence; […]
> | each instance of a ## preprocessing token in the replacement list
> | (not from an argument) is deleted and the preceding preprocessing
> | token is concatenated with the following preprocessing token.
> 
> Preprocessing tokens are defined in 6.4:
> | preprocessing-token:
> |   header-name
> |   identifier
> |   pp-number
> |   character-constant
> |   string-literal
> |   punctuator
> |   each non-white-space character that cannot be one of the above
> | […]
> | White space may appear within a preprocessing token only as part of
> | a header name or between the quotation characters in a character
> | constant or string literal.
> 
> So clang is wrong.
> 
> It should be noted that example 4 (6.10.3.5 6) shows such a space:
> 
>   #define glue(a, b)  a ## b
>   #define xglue(a, b) glue(a, b)
> 

I looked at this with a colleague who had clang installed on his
machine.  It looks as though this problem may only occur when
pre-processing assembly language files.  If so, that's somewhat unfortunate.

However, I'm not against taking a patch that's as trivial as this; it
doesn't harm how GCC handles this file.  It should however, be
accompanied by a comment explaining that it's for compatibility with LLVM.

R.
> 
> Regards,
> Clemens
> 

Re: Building newlib for Cortex-M with LLVM

[Olivier MARTIN]

On 12.11.2015 15:40, Richard Earnshaw wrote:
> On 12/11/15 12:33, Clemens Ladisch wrote:
>> Marcus Shawcroft wrote:
>>> On 11 November 2015 at 23:16, Olivier MARTIN <olivier@labapart.com> 
>>> wrote:
>>>> * 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:
>>>> 
>>>> -#define CONCAT(a, b)  CONCAT2(a, b)
>>>> +#define CONCAT(a, b)  CONCAT2(a,b)
>>> 
>>> Have you looked at the C standard on this issue? I wonder which
>>> compiler, gcc or clang is not compliant with the standard.
>> 
>> 6.10.3.3:
>> | If, in the replacement list of a function-like macro, a parameter is
>> | immediately preceded or followed by a ## preprocessing token, the
>> | parameter is replaced by the corresponding argument’s preprocessing
>> | token sequence; […]
>> | each instance of a ## preprocessing token in the replacement list
>> | (not from an argument) is deleted and the preceding preprocessing
>> | token is concatenated with the following preprocessing token.
>> 
>> Preprocessing tokens are defined in 6.4:
>> | preprocessing-token:
>> |   header-name
>> |   identifier
>> |   pp-number
>> |   character-constant
>> |   string-literal
>> |   punctuator
>> |   each non-white-space character that cannot be one of the above
>> | […]
>> | White space may appear within a preprocessing token only as part of
>> | a header name or between the quotation characters in a character
>> | constant or string literal.
>> 
>> So clang is wrong.
>> 
>> It should be noted that example 4 (6.10.3.5 6) shows such a space:
>> 
>>   #define glue(a, b)  a ## b
>>   #define xglue(a, b) glue(a, b)
>> 
> 
> I looked at this with a colleague who had clang installed on his
> machine.  It looks as though this problem may only occur when
> pre-processing assembly language files.  If so, that's somewhat 
> unfortunate.
> 
> However, I'm not against taking a patch that's as trivial as this; it
> doesn't harm how GCC handles this file.  It should however, be
> accompanied by a comment explaining that it's for compatibility with 
> LLVM.
> 
> R.
>> 
>> Regards,
>> Clemens
>> 

Yes, it is what I also noticed when I raised the clang issue earlier 
today: https://llvm.org/bugs/show_bug.cgi?id=25506

I am not sure it is worth to push a workaround in Newlib as this other 
issue I found 'Inline assembly does not support macro' 
https://llvm.org/bugs/show_bug.cgi?id=25495 is blocking.
-- 
Olivier
http://labapart.com - Lab A Part

Re: Building newlib for Cortex-M with LLVM

[Richard Earnshaw]

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.

Re: Building newlib for Cortex-M with LLVM

[Jonathan Roelofs]

[-- Attachment #1: Type: text/plain, Size: 1116 bytes --]



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

[-- Attachment #2: newlib-fix-for-clang-integrated-as.diff --]
[-- Type: text/plain, Size: 7412 bytes --]

commit b1053be367d1273c6d7b40e367423c3943a8302c
Author: Jonathan Roelofs <jonathan@codesourcery.com>
Date:   Thu Jul 10 09:28:03 2014 -0700

    Fix newlib build with Clang IAS. Need to -DCLANG_IAS when using -fintegrated-as

diff --git a/newlib-trunk/newlib/libc/aeabi/clibabi_signal_fns.S b/newlib-trunk/newlib/libc/aeabi/clibabi_signal_fns.S
index a4136f0..a7881b7 100644
--- a/newlib-trunk/newlib/libc/aeabi/clibabi_signal_fns.S
+++ b/newlib-trunk/newlib/libc/aeabi/clibabi_signal_fns.S
@@ -3,7 +3,11 @@
 	.macro sigfn name val
 	.global __aeabi_\name
 	.hidden __aeabi_\name
+#if defined(CLANG_IAS)
+	.type __aeabi_\name, %function
+#else
 	.type __aeabi_\name, function
+#endif
 	.set __aeabi_\name, \val
 	.endm
 	
diff --git a/newlib-trunk/newlib/libc/machine/arm/arm_asm.h b/newlib-trunk/newlib/libc/machine/arm/arm_asm.h
index 5a63a8d..06ca93d 100644
--- a/newlib-trunk/newlib/libc/machine/arm/arm_asm.h
+++ b/newlib-trunk/newlib/libc/machine/arm/arm_asm.h
@@ -78,21 +78,24 @@
 .endm
 
 #else
-asm(".macro  RETURN	cond=\n\t"
 #if defined (_ISA_ARM_4T) || defined (_ISA_THUMB_1)
-    "bx\\cond	lr\n\t"
+#define RETURN_MACRO ".macro  RETURN	cond=\n\t" \
+                     "bx\\cond	lr\n\t" \
+                     ".endm\n\t"
 #else
-    "mov\\cond	pc, lr\n\t"
+#define RETURN_MACRO ".macro  RETURN	cond=\n\t" \
+                     "mov\\cond	pc, lr\n\t" \
+                     ".endmi\n\t"
 #endif
-    ".endm"
-    );
 
-asm(".macro optpld	base, offset=#0\n\t"
 #if defined (_ISA_ARM_7)
-    "pld	[\\base, \\offset]\n\t"
+#define OPTPLD_MACRO ".macro optpld	base, offset=#0\n\t" \
+                     "pld	[\\base, \\offset]\n\t" \
+                     ".endm\n\t"
+#else
+#define OPTPLD_MACRO ".macro optpld	base, offset=#0\n\t" \
+                     ".endm\n\t"
 #endif
-    ".endm"
-    );
 #endif
 
 #endif /* ARM_ASM__H */
diff --git a/newlib-trunk/newlib/libc/machine/arm/setjmp.S b/newlib-trunk/newlib/libc/machine/arm/setjmp.S
index a65fbab..bb319d5 100644
--- a/newlib-trunk/newlib/libc/machine/arm/setjmp.S
+++ b/newlib-trunk/newlib/libc/machine/arm/setjmp.S
@@ -13,7 +13,11 @@
 #define SYM(x) CONCAT (__USER_LABEL_PREFIX__, x)
 
 #ifdef __ELF__
+#if defined(CLANG_IAS)
+#define TYPE(x) .type SYM(x),%function
+#else
 #define TYPE(x) .type SYM(x),function
+#endif
 #define SIZE(x) .size SYM(x), . - SYM(x)
 #else
 #define TYPE(x)
@@ -72,11 +76,19 @@ SYM (setjmp):
 	mov	r5, sp
 	mov	r6, lr
 	stmia	r0!, {r1, r2, r3, r4, r5, r6}
+#if defined(CLANG_IAS)
+	subs	r0, #40
+#else
 	sub	r0, r0, #40
+#endif
 	/* Restore callee-saved low regs.  */
 	ldmia	r0!, {r4, r5, r6, r7}
 	/* Return zero.  */
+#if defined(CLANG_IAS)
+	movs	r0, #0
+#else
 	mov	r0, #0
+#endif
 	bx lr
 
 .thumb_func
@@ -84,7 +96,11 @@ SYM (setjmp):
 	TYPE (longjmp)
 SYM (longjmp):
 	/* Restore High regs.  */
+#if defined(CLANG_IAS)
+	adds	r0, #16
+#else
 	add	r0, r0, #16
+#endif
 	ldmia	r0!, {r2, r3, r4, r5, r6}
 	mov	r8, r2
 	mov	r9, r3
@@ -93,12 +109,20 @@ SYM (longjmp):
 	mov	sp, r6
 	ldmia	r0!, {r3} /* lr */
 	/* Restore low regs.  */
+#if defined(CLANG_IAS)
+	subs	r0, #40
+#else
 	sub	r0, r0, #40
+#endif
 	ldmia	r0!, {r4, r5, r6, r7}
 	/* Return the result argument, or 1 if it is zero.  */
 	mov	r0, r1
 	bne	1f
+#if defined(CLANG_IAS)
+	movs	r0, #1
+#else
 	mov	r0, #1
+#endif
 1:
 	bx	r3
 
@@ -146,27 +170,25 @@ SYM (.arm_start_of.\name):
 .macro PROLOGUE name
 .endm
 #endif
-	
-.macro FUNC_START name
-	.text
-	.align 2
-	MODE
-	.globl SYM (\name)
-	TYPE (\name)
-SYM (\name):
-	PROLOGUE \name
-.endm
+#define FUNC_START(name) \
+	.text ;\
+	.align 2 ;\
+	MODE ;\
+	.globl SYM(name) ;\
+	TYPE(name) ;\
+SYM(name):\
+	PROLOGUE name
+
+#define FUNC_END(name) \
+	RET ; \
+	SIZE(name)
+
 
-.macro FUNC_END name
-	RET
-	SIZE (\name)
-.endm
-	
 /* --------------------------------------------------------------------
                  int setjmp (jmp_buf); 
    -------------------------------------------------------------------- */
 	
-	FUNC_START setjmp
+	FUNC_START(setjmp)
 
 	/* Save all the callee-preserved registers into the jump buffer.  */
 #ifdef __thumb2__
@@ -185,13 +207,13 @@ SYM (\name):
 	/* When setting up the jump buffer return 0.  */
 	mov		a1, #0
 
-	FUNC_END setjmp
+	FUNC_END(setjmp)
 	
 /* --------------------------------------------------------------------
 		volatile void longjmp (jmp_buf, int);
    -------------------------------------------------------------------- */
 	
-	FUNC_START longjmp
+	FUNC_START(longjmp)
 
 	/* If we have stack extension code it ought to be handled here.  */
 	
@@ -217,5 +239,5 @@ SYM (\name):
 #endif
 	moveq		a1, #1
 
-	FUNC_END longjmp
+	FUNC_END(longjmp)
 #endif
diff --git a/newlib-trunk/newlib/libc/machine/arm/strcpy.c b/newlib-trunk/newlib/libc/machine/arm/strcpy.c
index de96109..5ee3088 100644
--- a/newlib-trunk/newlib/libc/machine/arm/strcpy.c
+++ b/newlib-trunk/newlib/libc/machine/arm/strcpy.c
@@ -42,6 +42,8 @@ char* __attribute__((naked))
 strcpy (char* dst, const char* src)
 {
   asm (
+       OPTPLD_MACRO
+       RETURN_MACRO
 #if !(defined(__OPTIMIZE_SIZE__) || defined (PREFER_SIZE_OVER_SPEED) || \
       (defined (__thumb__) && !defined (__thumb2__)))
        "optpld	r1\n\t"
@@ -123,15 +125,28 @@ strcpy (char* dst, const char* src)
 #ifdef __ARMEB__
        "tst	r2, #0xff00\n\t"
        "iteet	ne\n\t"
+#if defined(CLANG_IAS)
+       "strhne	r2, [ip], #2\n\t"
+#else
        "strneh	r2, [ip], #2\n\t"
+#else
        "lsreq	r2, r2, #8\n\t"
+#if defined(CLANG_IAS)
+       "strbeq	r2, [ip]\n\t"
+#else
        "streqb	r2, [ip]\n\t"
+#endif
        "tstne	r2, #0xff\n\t"
 #else
        "tst	r2, #0xff\n\t"
        "itet	ne\n\t"
+#if defined(CLANG_IAS)
+       "strhne	r2, [ip], #2\n\t"
+       "strbeq	r2, [ip]\n\t"
+#else
        "strneh	r2, [ip], #2\n\t"
        "streqb	r2, [ip]\n\t"
+#endif
        "tstne	r2, #0xff00\n\t"
 #endif
        "bne	5b\n\t"
@@ -155,17 +170,21 @@ strcpy (char* dst, const char* src)
        "bne	1b\n\t"
        "RETURN"
 #else
+#if defined(CLANG_IAS)
+       "movs	r3, r0\n\t"
+#else
        "mov	r3, r0\n\t"
+#endif
   "1:\n\t"
        "ldrb	r2, [r1]\n\t"
-#if defined(__clang__)
-       "adds	r1, r1, #1\n\t"
+#if defined(CLANG_IAS)
+       "adds	r1, #1\n\t"
 #else
        "add	r1, r1, #1\n\t"
 #endif
        "strb	r2, [r3]\n\t"
-#if defined(__clang__)
-       "adds	r3, r3, #1\n\t"
+#if defined(CLANG_IAS)
+       "adds	r3, #1\n\t"
 #else
        "add	r3, r3, #1\n\t"
 #endif
diff --git a/newlib-trunk/newlib/libc/machine/arm/strlen.c b/newlib-trunk/newlib/libc/machine/arm/strlen.c
index ed60e95..aefe01d 100644
--- a/newlib-trunk/newlib/libc/machine/arm/strlen.c
+++ b/newlib-trunk/newlib/libc/machine/arm/strlen.c
@@ -41,17 +41,17 @@ strlen (const char* str)
 #if defined (__thumb__) && !defined (__thumb2__)
   size_t len;
   asm (
-#if defined(__clang__)
+#if defined(CLANG_IAS)
        "movs	%0, #0\n"
 #else
        "mov	%0, #0\n"
 #endif
        "1:\n\t"
        "ldrb	%1, [%2, %0]\n\t"
-#if defined(__clang__)
-       "adds 	%0, %0, #1\n\t"
+#if defined(CLANG_IAS)
+       "adds	%0, #1\n\t"
 #else
-       "add 	%0, %0, #1\n\t"
+       "add	%0, %0, #1\n\t"
 #endif
        "cmp	%1, #0\n\t"
        "bne	1b"
@@ -74,7 +74,10 @@ strlen (const char* str)
 size_t __attribute__((naked))
 strlen (const char* str)
 {
-  asm ("len .req r0\n\t"
+  asm (
+       OPTPLD_MACRO
+       RETURN_MACRO
+       "len .req r0\n\t"
        "data .req r3\n\t"
        "addr .req r1\n\t"
 

Re: Building newlib for Cortex-M with LLVM

[Emmanuel Blot]

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