* Building newlib for Cortex-M with LLVM
@ 2015-11-12 4:11 Olivier MARTIN
2015-11-12 11:17 ` Marcus Shawcroft
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Olivier MARTIN @ 2015-11-12 4:11 UTC (permalink / raw)
To: newlib; +Cc: olivier
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Building newlib for Cortex-M with LLVM
2015-11-12 4:11 Building newlib for Cortex-M with LLVM Olivier MARTIN
@ 2015-11-12 11:17 ` Marcus Shawcroft
2015-11-12 12:39 ` Clemens Ladisch
2015-11-12 15:59 ` Richard Earnshaw
2015-11-12 22:42 ` Jonathan Roelofs
2 siblings, 1 reply; 11+ messages in thread
From: Marcus Shawcroft @ 2015-11-12 11:17 UTC (permalink / raw)
To: Olivier MARTIN; +Cc: Newlib Mailing List
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Building newlib for Cortex-M with LLVM
2015-11-12 11:17 ` Marcus Shawcroft
@ 2015-11-12 12:39 ` Clemens Ladisch
2015-11-12 13:46 ` Olivier MARTIN
2015-11-12 15:50 ` Richard Earnshaw
0 siblings, 2 replies; 11+ messages in thread
From: Clemens Ladisch @ 2015-11-12 12:39 UTC (permalink / raw)
To: Marcus Shawcroft, Olivier MARTIN; +Cc: Newlib Mailing List
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Building newlib for Cortex-M with LLVM
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:50 ` Richard Earnshaw
1 sibling, 1 reply; 11+ messages in thread
From: Olivier MARTIN @ 2015-11-12 13:46 UTC (permalink / raw)
To: Clemens Ladisch; +Cc: Marcus Shawcroft, Newlib Mailing List, olivier
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Building newlib for Cortex-M with LLVM
2015-11-12 13:46 ` Olivier MARTIN
@ 2015-11-12 14:22 ` Richard Earnshaw
2015-11-12 15:33 ` Olivier MARTIN
0 siblings, 1 reply; 11+ messages in thread
From: Richard Earnshaw @ 2015-11-12 14:22 UTC (permalink / raw)
To: Olivier MARTIN, Clemens Ladisch; +Cc: Marcus Shawcroft, Newlib Mailing List
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Building newlib for Cortex-M with LLVM
2015-11-12 14:22 ` Richard Earnshaw
@ 2015-11-12 15:33 ` Olivier MARTIN
0 siblings, 0 replies; 11+ messages in thread
From: Olivier MARTIN @ 2015-11-12 15:33 UTC (permalink / raw)
To: Richard Earnshaw; +Cc: Clemens Ladisch, Marcus Shawcroft, Newlib Mailing List
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Building newlib for Cortex-M with LLVM
2015-11-12 12:39 ` Clemens Ladisch
2015-11-12 13:46 ` Olivier MARTIN
@ 2015-11-12 15:50 ` Richard Earnshaw
2015-11-12 15:56 ` Olivier MARTIN
1 sibling, 1 reply; 11+ messages in thread
From: Richard Earnshaw @ 2015-11-12 15:50 UTC (permalink / raw)
To: Clemens Ladisch, Marcus Shawcroft, Olivier MARTIN; +Cc: Newlib Mailing List
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
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Building newlib for Cortex-M with LLVM
2015-11-12 15:50 ` Richard Earnshaw
@ 2015-11-12 15:56 ` Olivier MARTIN
0 siblings, 0 replies; 11+ messages in thread
From: Olivier MARTIN @ 2015-11-12 15:56 UTC (permalink / raw)
To: Richard Earnshaw; +Cc: Clemens Ladisch, Marcus Shawcroft, Newlib Mailing List
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Building newlib for Cortex-M with LLVM
2015-11-12 4:11 Building newlib for Cortex-M with LLVM Olivier MARTIN
2015-11-12 11:17 ` Marcus Shawcroft
@ 2015-11-12 15:59 ` Richard Earnshaw
2015-11-12 22:42 ` Jonathan Roelofs
2 siblings, 0 replies; 11+ messages in thread
From: Richard Earnshaw @ 2015-11-12 15:59 UTC (permalink / raw)
To: Olivier MARTIN, newlib
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Building newlib for Cortex-M with LLVM
2015-11-12 4:11 Building newlib for Cortex-M with LLVM Olivier MARTIN
2015-11-12 11:17 ` Marcus Shawcroft
2015-11-12 15:59 ` Richard Earnshaw
@ 2015-11-12 22:42 ` Jonathan Roelofs
2017-06-15 10:52 ` Emmanuel Blot
2 siblings, 1 reply; 11+ messages in thread
From: Jonathan Roelofs @ 2015-11-12 22:42 UTC (permalink / raw)
To: Olivier MARTIN, newlib
[-- 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"
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Building newlib for Cortex-M with LLVM
2015-11-12 22:42 ` Jonathan Roelofs
@ 2017-06-15 10:52 ` Emmanuel Blot
0 siblings, 0 replies; 11+ messages in thread
From: Emmanuel Blot @ 2017-06-15 10:52 UTC (permalink / raw)
To: newlib
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
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2017-06-15 10:52 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-11-12 4:11 Building newlib for Cortex-M with LLVM 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 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).