Port, board and/or hardware

Unix port (Linux)

MicroPython version

MicroPython v1.27.0-preview.252.gb2871e0d0a on 2025-10-02; linux [GCC 14.2.0] version

Reproduction

sudo apt install qemu-user-static gcc-m68k-linux-gnu

make -C mpy-cross

make -C ports/unix \
    DEBUG=1 \
    CROSS_COMPILE=m68k-linux-gnu- \
    LDFLAGS_EXTRA=-static \
    MICROPY_STANDALONE=1 \
    MICROPY_PY_BTREE=0 \
    MICROPY_PY_FFI=0

qemu-m68k-static ports/unix/build-standard/micropython

FATAL: uncaught NLR 0xc0807ec0

Expected behaviour

Expected to launch REPL

Observed behaviour

I am testing the compilation of MicroPython binaries for different architectures, using either glibc or musl, and running them with qemu-user.

Most of the binaries work as expected, but the m68k binary refuses to start and throws an "uncaught NLR" error.

$ qemu-m68k-static -g 1234 ports/unix/build-standard/micropython &
$ gdb-multiarch
...
(gdb) target remote :1234
Remote debugging using :1234
...
0x80000328 in _start ()
(gdb) b nlr_jump_fail
Breakpoint 1 at 0x80065adc: file main.c, line 808.
(gdb) c
Continuing.

Breakpoint 1, nlr_jump_fail (val=0xc0807ec0) at main.c:808
808         mp_hal_stdio_mode_orig();
(gdb) bt
#0  nlr_jump_fail (val=0xc0807ec0) at main.c:808
#1  0x800004ae in nlr_jump (val=0xc0807ec0) at ../../py/nlrsetjmp.c:32
#2  0x80010928 in mp_raise_msg_varg (exc_type=0x8010f500 <mp_type_TypeError>, fmt=0x801007c4) at ../../py/runtime.c:1715
#3  0x80010c68 in mp_call_function_n_kw (fun_in=0x8011785a <vfs_posix_mount_obj>, n_args=2, n_kw=0, args=0xc07ffa74) at build-standard/genhdr/compressed.data.h:13
#4  0x80010da0 in mp_call_method_n_kw (n_args=2, n_kw=0, args=0xc07ffa6c) at ../../py/runtime.c:728
#5  0x800359b8 in mp_vfs_proxy_call (vfs=0xc0807e60, meth_name=585, n_args=2, args=0xc07ffac4) at ../../extmod/vfs.c:128
#6  0x80035eca in mp_vfs_mount (n_args=2, pos_args=0xc07ffb08, kw_args=0x8010f3f0 <mp_const_empty_dict_obj+4>) at ../../extmod/vfs.c:257
#7  0x800654f2 in main_ (argc=1, argv=0xc07ffda4) at main.c:554
#8  0x80065ad6 in main (argc=1, argv=0xc07ffda4) at main.c:494
(gdb) 

Additional Information

In some odd cases, vfs.mount() called by the startup code in ports/unix/main.c can fail. Then the program will exit with "FATAL: uncaught NLR ..." not printing the error message.

Do we need to add nlr_push / nlr_pop and handle_uncaught_exception processing on it?

---

Update:

The vfs.mount() failure is caused by the wrong result from mp_obj_get_type(). That raises a TypeError.

#1  0x80002bce in mp_vprintf (print=0xc07ff9bc, fmt=0xc07ff9d6 "' object isn't callable", args=<optimized out>) at ../../py/mpprint.c:399
#2  0x80017f98 in mp_obj_new_exception_msg_vlist (exc_type=0x8010f500 <mp_type_TypeError>, fmt=0x801007c4, args=0xc07ffa44) at ../../py/objexcept.c:523
#3  0x80010920 in mp_raise_msg_varg (exc_type=0x8010f500 <mp_type_TypeError>, fmt=0x801007c4) at ../../py/runtime.c:1713
#4  0x80010c68 in mp_call_function_n_kw (fun_in=0x8011785a <vfs_posix_mount_obj>, n_args=2, n_kw=0, args=0xc07ffa84) at build-standard/genhdr/compressed.data.h:13
#5  0x80010da0 in mp_call_method_n_kw (n_args=2, n_kw=0, args=0xc07ffa7c) at ../../py/runtime.c:728
#6  0x800359b8 in mp_vfs_proxy_call (vfs=0xc0807e60, meth_name=585, n_args=2, args=0xc07ffad4) at ../../extmod/vfs.c:128
#7  0x80035eca in mp_vfs_mount (n_args=2, pos_args=0xc07ffb18, kw_args=0x8010f3f0 <mp_const_empty_dict_obj+4>) at ../../extmod/vfs.c:257
#8  0x800654f2 in main_ (argc=1, argv=0xc07ffdb4) at main.c:554
#9  0x80065ad6 in main (argc=1, argv=0xc07ffdb4) at main.c:494

The default alignment on m68k is 2 bytes instead of 4 bytes. See #18194

Code of Conduct

Yes, I agree