Compile error on Android Armv7l with Clang

[jickster]

I gave you a fix.

Yes, I will test that later.

Someone on Stack pointed this out:

Naked functions don't have prologues or epilogues, so doing
codegen for anything other than inline assembly would be completely
hit or miss.

http://lists.llvm.org/pipermail/cfe-com ... 14153.html

but I don't understand why gcc can seem to do it fine.

[SpotlightKid]

Interestingly, on my Raspberry Pi 3 I get a different error when compiling with Clang (has the rather old version 3.5.0, though):

Code: Select all

$ make CC=clang V=1
python ../../py/makeversionhdr.py build/genhdr/mpversion.h
CC ../../py/asmarm.c
clang -I../../lib/berkeley-db-1.xx/PORT/include -I. -I../.. -Ibuild -I../../lib/mp-readline -Wall -Werror -Wpointer-arith -Wuninitialized -std=gnu99 -DUNIX -DFFCONF_H=\"lib/oofatfs/ffconf.h\" -DMICROPY_PY_USSL=1 -DMICROPY_SSL_AXTLS=1 -I../../lib/axtls/ssl -I../../lib/axtls/crypto -I../../lib/axtls/config -DMICROPY_PY_BTREE=1 -DMICROPY_USE_READLINE=1 -DMICROPY_PY_TERMIOS=1 -DMICROPY_PY_SOCKET=1 -DMICROPY_PY_THREAD=1 -DMICROPY_PY_THREAD_GIL=0  -DMICROPY_PY_FFI=1 -Os -fdata-sections -ffunction-sections -DNDEBUG  -U _FORTIFY_SOURCE -DMICROPY_QSTR_EXTRA_POOL=mp_qstr_frozen_const_pool -DMICROPY_MODULE_FROZEN_MPY -DMPZ_DIG_SIZE=16  -c -MD -o build/py/asmarm.o ../../py/asmarm.c
../../py/asmarm.c:46:17: error: invalid operand for instruction
                "0:"
                ^
<inline asm>:1:19: note: instantiated into assembly here
        0:mrc p15, 0, r15, c7, c10, 3
                         ^
1 error generated.
../../py/mkrules.mk:47: recipe for target 'build/py/asmarm.o' failed
make: *** [build/py/asmarm.o] Error 1

Code: Select all

$ 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

$ uname -a
Linux DietPi 4.9.23-v7+ #989 SMP Wed Apr 19 15:29:25 BST 2017 armv7l GNU/Linux

$ cat /proc/cpuinfo 
processor	: 0
model name	: ARMv7 Processor rev 4 (v7l)
BogoMIPS	: 38.40
Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xd03
CPU revision	: 4

processor	: 1
model name	: ARMv7 Processor rev 4 (v7l)
BogoMIPS	: 38.40
Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xd03
CPU revision	: 4

processor	: 2
model name	: ARMv7 Processor rev 4 (v7l)
BogoMIPS	: 38.40
Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xd03
CPU revision	: 4

processor	: 3
model name	: ARMv7 Processor rev 4 (v7l)
BogoMIPS	: 38.40
Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xd03
CPU revision	: 4

Hardware	: BCM2835
Revision	: a22082
Serial		: XXXXXXXXXXXXXXXXX

Compilation with GCC produces a working micropython binary.

Code: Select all

$ gcc --version
gcc (Raspbian 4.9.2-10) 4.9.2

[jickster]

Interestingly, on my Raspberry Pi 3 I get a different error when compiling with Clang (has the rather old version 3.5.0, though):

Code: Select all

$ make CC=clang V=1
python ../../py/makeversionhdr.py build/genhdr/mpversion.h
CC ../../py/asmarm.c
clang -I../../lib/berkeley-db-1.xx/PORT/include -I. -I../.. -Ibuild -I../../lib/mp-readline -Wall -Werror -Wpointer-arith -Wuninitialized -std=gnu99 -DUNIX -DFFCONF_H=\"lib/oofatfs/ffconf.h\" -DMICROPY_PY_USSL=1 -DMICROPY_SSL_AXTLS=1 -I../../lib/axtls/ssl -I../../lib/axtls/crypto -I../../lib/axtls/config -DMICROPY_PY_BTREE=1 -DMICROPY_USE_READLINE=1 -DMICROPY_PY_TERMIOS=1 -DMICROPY_PY_SOCKET=1 -DMICROPY_PY_THREAD=1 -DMICROPY_PY_THREAD_GIL=0  -DMICROPY_PY_FFI=1 -Os -fdata-sections -ffunction-sections -DNDEBUG  -U _FORTIFY_SOURCE -DMICROPY_QSTR_EXTRA_POOL=mp_qstr_frozen_const_pool -DMICROPY_MODULE_FROZEN_MPY -DMPZ_DIG_SIZE=16  -c -MD -o build/py/asmarm.o ../../py/asmarm.c
../../py/asmarm.c:46:17: error: invalid operand for instruction
                "0:"
                ^
<inline asm>:1:19: note: instantiated into assembly here
        0:mrc p15, 0, r15, c7, c10, 3
                         ^
1 error generated.
../../py/mkrules.mk:47: recipe for target 'build/py/asmarm.o' failed
make: *** [build/py/asmarm.o] Error 1

Code: Select all

$ 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

$ uname -a
Linux DietPi 4.9.23-v7+ #989 SMP Wed Apr 19 15:29:25 BST 2017 armv7l GNU/Linux

$ cat /proc/cpuinfo 
processor	: 0
model name	: ARMv7 Processor rev 4 (v7l)
BogoMIPS	: 38.40
Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xd03
CPU revision	: 4

processor	: 1
model name	: ARMv7 Processor rev 4 (v7l)
BogoMIPS	: 38.40
Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xd03
CPU revision	: 4

processor	: 2
model name	: ARMv7 Processor rev 4 (v7l)
BogoMIPS	: 38.40
Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xd03
CPU revision	: 4

processor	: 3
model name	: ARMv7 Processor rev 4 (v7l)
BogoMIPS	: 38.40
Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xd03
CPU revision	: 4

Hardware	: BCM2835
Revision	: a22082
Serial		: XXXXXXXXXXXXXXXXX

Compilation with GCC produces a working micropython binary.

Code: Select all

$ gcc --version
gcc (Raspbian 4.9.2-10) 4.9.2

So no more issues then?

[SpotlightKid]

Well, apart from that compiling MicroPython with Clang on armv7l currently is not supported/working, no

I'll try with Clang 5.0.0 on the raspi as well (with the binaries form here), I first need to upgrade the system to a bigger microSD though

[jickster]

Well, apart from that compiling MicroPython with Clang on armv7l currently is not supported/working, no

I'll try with Clang 5.0.0 on the raspi as well (with the binaries form here), I first need to upgrade the system to a bigger microSD though

(1) it's your compiler that's the issue

(2) I already told you the workaround. Twice.

Go to nlr.h and at the top, add

Code: Select all

#define MICROPY_NLR_SETJMP 1

This will configure the build to not use the functions that use assembly for exceptions. It'll probably be slower if there's a lot of exceptions but should work.

[SpotlightKid]

I'm not interested in a workaround. I'm interested in improving MicroPython so that it compiles cleanly out of the box with Clang.

[jickster]

I'm not interested in a workaround. I'm interested in improving MicroPython so that it compiles cleanly out of the box with Clang.

There's nothing to improve with micropython to "fix" this issue. Your compiler doesn't want to allow non-ASM statements in naked functions so you should improve Clang if you want it to compile non-ASM statements in naked functions.

"Out of the box" with software of any complexity is meaningless: of course there's going to have to be some configuration.

If you luck out, sure you may be able to compile it without modifying anything in mpconfigport.h or nlr.h but that's the exception.

Why do you think there's so many #if #elif macros below?

Code: Select all

struct _nlr_buf_t {
    // the entries here must all be machine word size
    nlr_buf_t *prev;
    void *ret_val; // always a concrete object (an exception instance)
#if !defined(MICROPY_NLR_SETJMP) || !MICROPY_NLR_SETJMP
#if defined(__i386__)
    void *regs[6];
#elif defined(__x86_64__)
  #if defined(__CYGWIN__)
    void *regs[12];
  #else
    void *regs[8];
  #endif
#elif defined(__thumb2__) || defined(__thumb__) || defined(__arm__)
    void *regs[10];
#elif defined(__xtensa__)
    void *regs[10];
#else
    #define MICROPY_NLR_SETJMP (1)
    //#warning "No native NLR support for this arch, using setjmp implementation"
#endif
#endif

It's so you can configure it to your needs. If your needs are to use Clang, then you need to add #define MICROPY_NLR_SETJMP 1 in nlr.h

Here is the exact commit to Clang where they decided to add this constraint
Don't allow non-ASM statements in naked functions
https://reviews.llvm.org/rL217199

[SpotlightKid]

The point is that the C instructions in the naked functions aren't really necessary, don't really make sense, and are just there to (probably) silence GCC warnings. They should probably be guarded if #ifdefs.

[jickster]

The point is that the C instructions in the naked functions aren't really necessary, don't really make sense, and are just there to (probably) silence GCC warnings. They should probably be guarded if #ifdefs.

That’s exactly why it’s there; the comment says so.




Sent from my iPhone using Tapatalk

[stijn]

it's your compiler that's the issue

Looks like in this case one could equally well say MicroPython's code is the issue here: it works ok for one compiler but not the other on some code which is (as far as I know) not subject to any real standard. Should this be some valid C99 code which gets rejected by the compiler, then yes, the compiler is an issue. (but that still wouldn't mean per se the source code of MicroPython should not be adapted to work with it)

The point is that the C instructions in the naked functions aren't really necessary, don't really make sense, and are just there to (probably) silence GCC warnings. They should probably be guarded if #ifdefs.

If that fixes the whole issue, create a PR for it: Clang is a pretty major compiler so I don't see why the maintainers would object against a simple fix which allows the code to work with it without having to resort to setjmp.