Compile error on Android Armv7l with Clang

[SpotlightKid]

Unfortunately, it's not so easy.

Two of the functions in "py/nlrthumb.c" with inline assembler have C statements, which are apparently there just to placate GCC. I tried guarding them with

Code: Select all

#if defined(__GNUC__)  && !defined(__clang__)

but the function "nlr_thumb" also has more C statements at the beginning, which actually do something.

Also, I tried the fix suggested by jiggster to add

Code: Select all

#define MICROPY_NLR_SETJMP 1

to "py/nlr.h", but that only unearthed another Clang incompatibility in "py/asmarm.c" (see the error message I put in my post on the Raspberry Pi above).

My knowledge of what's going on there is not enough to suggest a sensible fix.

OTOH, I found some unofficial packages to install GCC 6 for armv7 in my Termux environment on my Android phone, so now I'm able to compile MicroPython there. But I might still bring up the Clang incompatibility issues on Github.

[stijn]

Sorry I missed that part about the other asm statements; the assembly written is likely some gcc dialect. However you don't really need asmarm.c to get a working executable: #define MICROPY_EMIT_ARM (0) in your mpconfigport.h and it will skip what's in asmarm.c

[SpotlightKid]

@stijn @jickster: thanks for the tips!

[stijn]

I tried to build MicroPython on a Raspberry Pi 3 here

Code: Select all

>> uname -a
Linux rpi 4.4.50-v7+ #970 SMP Mon Feb 20 19:18:29 GMT 2017 armv7l GNU/Linux

>> clang --version
Raspbian clang version 3.5.0-10+rpi1 (tags/RELEASE_350/final) (based on LLVM 3.5.0)
Target: arm-unknown-linux-gnueabihf
Thread model: posix

and that sort of works: as said it needs #define MICROPY_EMIT_ARM (0) in the mpconfigport.h, and then there was still this:

Code: Select all

gccollect.c:116:14: error: variable 'r4' is uninitialized when used here [-Werror,-Wuninitialized]
    arr[0] = r4;

Not a good sign but after removing -Wuninitialized everything builds but the resulting executable segfaults when gc kicks in which I sort of expected: I assume the assembly used is written for gcc/non-arm or so and is not entirely correct for use with clang/arm. Using the stjmp based version (#define MICROPY_NLR_SETJMP (1) in mpconfigport.h) does produce a working version though and all tests pass.

So since you stated interest in fixing MicroPython so it compiles out of the box with clang I'd suggest a PR which figures out if clang is used (on arm, I guess, never tried on linux) and if so uses the 2 defines above in linux/mpconfigport.h. The alternative is fixing the assembly used (for the NLR stuff that might not be too hard, possibly just needs different registers to be used).

[SpotlightKid]

Version 3.5 of Clang doesn't produce an error, when a naked function with inline asm contains C code. That was only explicitly forbidden later.

I booted Arch Linux ARM on my Raspberry Pi 3 - the Rapsi 2 version for armv7 architecture - so I could use Clang 5.