emitnative: Make ARM codegen compile after full-arg support refactors.

[pfalcon]

The code was apparently broken after 9988618
"py: Implement full func arg passing for native emitter.". However,
while these changes make it compile, it still crashes at runtime and need
more work.

[pfalcon]

@Vogtinator: It would be nice if looked into this.

@dpgeorge: Maybe you'd know how to quickly fix it, based on transformations you applied to other archs in mentioned commit. Also let me know if you agree this should be catchable by Travis (note that for example regarding stackless, I handle that separately in https://github.com/pfalcon/micropython/tree/stackless-travis , not not burden common CI).

[coveralls]

Coverage increased (+0.0%) to 92.85% when pulling e877e30 on pfalcon:unbreak-native-arm into 76abb2e on micropython:master.

[dpgeorge]

I didn't have the time to fix all native emitters, and thought it better to actually push some code rather than leave it forever :) I don't currently have a way of testing the ARM emitter; how do you do it?

[dpgeorge]

Probably off is a word offset so needs shifting right by 4.

[pfalcon]

I didn't have the time to fix all native emitters, and thought it better to actually push some code rather than leave it forever :) I don't currently have a way of testing the ARM emitter; how do you do it?

Sure, supporting all arg variety was a great addition for native emitter. I popped up Samsung ARM Chromebook after not using it for a while, and tried to build uPy. It crashes, and running thru gdb, control is passed to something which doesn't look like valid ARM code.

[dpgeorge]

mp_setup_code_state takes 5 args so need special handling on thumb/arm (since 5th arg goes on stack). Therefore you need to duplicate lines 750-752 (of file before this patch) for the N_ARM case.

[pfalcon]

Thanks for the hint, doesn't seem to help, behavior is the same as before.

$ gdb --args micropython native_const.py
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
Reading symbols from micropython...done.
(gdb) r
Starting program: /home/pfalcon/bin/micropython native_const.py

Program received signal SIGSEGV, Segmentation fault.
0xb6ff8008 in ?? ()
(gdb) bt
#0  0xb6ff8008 in ?? ()
#1  0x0002aeb4 in fun_native_call (self_in=0xb6dd2d80, n_args=0, n_kw=0, args=0xbeffe1d0) at ../py/objfun.c:366
#2  0x00023a10 in mp_call_function_n_kw (fun_in=0xb6dd2d80, n_args=0, n_kw=0, args=0xbeffe1d0) at ../py/runtime.c:560
#3  0x0003bd70 in mp_execute_bytecode (code_state=0xbeffe1b0, inject_exc=<optimized out>) at ../py/vm.c:1048
#4  0x0002ac84 in fun_bc_call (self_in=0xb6dd2c20, n_args=0, n_kw=0, args=0x0) at ../py/objfun.c:241
#5  0x00023a10 in mp_call_function_n_kw (fun_in=0xb6dd2c20, n_args=0, n_kw=0, args=0x0) at ../py/runtime.c:560
#6  0x0002398c in mp_call_function_0 (fun=0xb6dd2c20) at ../py/runtime.c:534
#7  0x00042d0e in execute_from_lexer (lex=0xb6dd2da0, input_kind=MP_PARSE_FILE_INPUT, is_repl=false) at main.c:137
#8  0x00042e8a in do_file (file=0xbefff6d3 "native_const.py") at main.c:203
#9  0x00043ab0 in main (argc=2, argv=0xbefff564) at main.c:462
(gdb) disass/r 0xb6ff8008,+0x20
Dump of assembler code from 0xb6ff8008 to 0xb6ff8028:
=> 0xb6ff8008:  0a 46 01 46 strmi   r4, [r1], -r10, lsl #12
   0xb6ff800c:  44 20 00 90 andls   r2, r0, r4, asr #32
   0xb6ff8010:  48 20 01 90 andls   r2, r1, r8, asr #32
   0xb6ff8014:  01 20 05 90 andls   r2, r5, r1
   0xb6ff8018:  00 a8 10 b4 ldrlt   r10, [r0], #-2048   ; 0x800
   0xb6ff801c:  4c f2 09 64 strvs   pc, [r9], #-588 ; 0x24c
   0xb6ff8020:  c0 f2 03 04 streq   pc, [r3], #-704 ; 0x2c0
   0xb6ff8024:  a0 47 01 bc stclt   7, cr4, [r1], {160} ; 0xa0
End of assembler dump.

[pfalcon]

What actually gets called:

365     mp_call_fun_t fun = MICROPY_MAKE_POINTER_CALLABLE((void*)self->bytecode);
(gdb) s
366     return fun(self_in, n_args, n_kw, args);
(gdb) p fun
$1 = (mp_call_fun_t) 0xb6ff8000

[pfalcon]

So, there's some pretty weird mess. Code actually thumb2, but appears to be called as arm, and it somehow thinks that it's arm mode (though it's ubuntu armhf, and i'd think it'd use thumb2). So, looks some kind of miss-detection and mix up. (It all used to work of course.)

(gdb) disass/r 0xb6ff8000,+0x30
Dump of assembler code from 0xb6ff8000 to 0xb6ff8030:
   0xb6ff8000:  fe b5   push    {r1, r2, r3, r4, r5, r6, r7, lr}
   0xb6ff8002:  84 b0   sub sp, #16
   0xb6ff8004:  1c 46   mov r4, r3
   0xb6ff8006:  13 46   mov r3, r2
   0xb6ff8008:  0a 46   mov r2, r1
   0xb6ff800a:  01 46   mov r1, r0
   0xb6ff800c:  44 20   movs    r0, #68 ; 0x44
   0xb6ff800e:  00 90   str r0, [sp, #0]
   0xb6ff8010:  48 20   movs    r0, #72 ; 0x48
   0xb6ff8012:  01 90   str r0, [sp, #4]
   0xb6ff8014:  01 20   movs    r0, #1
   0xb6ff8016:  05 90   str r0, [sp, #20]
   0xb6ff8018:  00 a8   add r0, sp, #0
   0xb6ff801a:  10 b4   push    {r4}
   0xb6ff801c:  4c f2 09 64 movw    r4, #50697  ; 0xc609
   0xb6ff8020:  c0 f2 03 04 movt    r4, #3
   0xb6ff8024:  a0 47   blx r4
   0xb6ff8026:  01 bc   pop {r0}
   0xb6ff8028:  4c f6 c4 07 movw    r7, #51396  ; 0xc8c4

[dpgeorge]

MICROPY_MAKE_POINTER_CALLABLE(p) should be setting the low bit in order to jump to Thumb2 code; copy the relevant line from stmhal/mpconfigport.h.

[pfalcon]

Well, it detected both arm and thumb2. they should be prioritized, and yep, MICROPY_MAKE_POINTER_CALLABLE(p) for thumb was missing.

[pfalcon]

Well, it detected both arm and thumb2. they should be prioritized

Or how case of multiple emitters should be handled? (Taking into account that MICROPY_MAKE_POINTER_CALLABLE is global.)

[coveralls]

Coverage decreased (-0.0%) to 92.85% when pulling e877e30 on pfalcon:unbreak-native-arm into 76abb2e on micropython:master.

[pfalcon]

Updated patch, all native tests pass. Few viper ones fail though.

[coveralls]

Coverage decreased (-0.0%) to 93.45% when pulling bb53f34 on pfalcon:unbreak-native-arm into d3b32ca on micropython:master.

[dpgeorge]

Merged in 351424e.