from src/rp2_common/pico_crt0/crt0.S in the pico-sdk
here, we can see that it first runs runtime_init(), which deals with the functions tagged as constructor
then it runs main()
and finally, it runs exit()
and then if we look at src/rp2_common/pico_clib_interface/newlib_interface.cso on exit, it may go into bootloader mode, and if not, it will just trigger a breakpoint and halt
so the problem is that the current pico-sdk doesnt support the destructor functions, and you just need to ensure main calls them at the right time
Code:
platform_entry: // symbol for stack traces // Use 32-bit jumps, in case these symbols are moved out of branch range // (e.g. if main is in SRAM and crt0 in flash)#if !__ARM_ARCH_6M__ // Make sure stack limit is 0 - the user can set it themselves // todo probably worth adding to the EXE_DEF in the future movs r0, #0 msr msplim, r0#endif ldr r1, =runtime_init blx r1 ldr r1, =main blx r1 ldr r1, =exit blx r1 // exit should not return. If it does, hang the core.1: // separate label because _exit can be moved out of branch range bkpt #0 b 1bthen it runs main()
and finally, it runs exit()
and then if we look at src/rp2_common/pico_clib_interface/newlib_interface.c
Code:
// exit is not useful... no desire to pull in __call_exitprocsvoid exit(int status) { _exit(status);}void __attribute__((noreturn)) __weak _exit(__unused int status) {#if PICO_ENTER_USB_BOOT_ON_EXIT reset_usb_boot(0,0);#else while (1) { __breakpoint(); }#endif}so the problem is that the current pico-sdk doesnt support the destructor functions, and you just need to ensure main calls them at the right time
Statistics: Posted by cleverca22 — Mon Jul 28, 2025 11:59 am