I'd like to submit a PR soon for changing the MP_STATE_XXX(x) macros so that they access the current state through a pointer. I was up-to-date with the repo at commit [41e7ad647] then I diverged and got demo code working on an ESP32. Now I'm making the effort to consolidate my changes into a neat and minimal PR. I started with a recent commit ec6e62efc and began making the essential changes when I found trouble with the NLR code.
Wow, I don't even know what NLR stands for an am having trouble finding it online but I get the impression that NLR is handling exceptions. So, usually I'm gung-ho to research a problem out of curiosity but that energy all drained out of me staring at assembly for x64 and several other platforms...
Here's what I'm seeing:
Code: Select all
LINK mpy-cross
Undefined symbols for architecture x86_64:
"_p_mp_active_state_ctx", referenced from:
_nlr_push_tail in nlr.o
_nlr_pop in nlr.o
_nlr_jump in nlrx64.o
_gc_init in gc.o
_gc_lock in gc.o
_gc_unlock in gc.o
_gc_is_locked in gc.o
...
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [mpy-cross] Error 1
Code: Select all
#define MP_STATE_THREAD(x)
Code: Select all
(mp_state_ctx.thread.x)
Code: Select all
(p_mp_active_state_ctx->thread.x)
In thumb, x64, x86, and xtensa ___nlr.c files (in 'void nlr_jump( void )') we see the MP_NLR_JUMP_HEAD(val, top) macro which uses the THREAD macro mentioned above, however the macro is not inside the inline assembly... And ultimately the type of the thing accessed via pointer is still the same. This calls to mind how after this change you cannot use the STATE macros in initializer lists because access through a pointer isn't constant. Is this related?
So can someone help explain to me why this pointer access doesn't work here? Even better can someone point me in the right direction to fix this? Will I need to go learn assembly for these platforms?
Thanks!