Hm, it seems I've found a workaround, thanks to https://stackoverflow.com/questions/588 ... ess-in-gdb - instead of trying to coax interpretation of the watch target as a `mutex_t` type variable, simply interpret it as an integer. First, I did some copy-pasting from the SDK, and the definitions are:
So basically I'd need 4 bytes for .core, and 1 byte for .owner - so i thought, if I "interpret"/cast `mutex_t` as `uint32_t`, it should at least follow changes to mutex_t.core - but it seemingly does more than that?
So it seems here I'm seeing changes on both .core.spin_lock, and .owner ...
Hopefully someone more knowledgeable can explain this at a certain point - but it seems to me, for the time being this workaround works for RP2040 ...
Code:
typedef struct mutex { lock_core_t core; lock_owner_id_t owner; //! owner id LOCK_INVALID_OWNER_ID for unowned} mutex_t;struct lock_core { // spin lock protecting this lock's state spin_lock_t *spin_lock; // note any lock members in containing structures need not be volatile; // they are protected by memory/compiler barriers when gaining and release spin locks};typedef struct lock_core lock_core_t;typedef io_rw_32 spin_lock_t;typedef SW_SPIN_LOCK_TYPE spin_lock_t;#define lock_owner_id_t int8_tCode:
(gdb) watch *(uint32_t*)0x200096bcHardware watchpoint 4: *(uint32_t*)0x200096bc(gdb) info brNum Type Disp Enb Address What3 breakpoint keep y 0x2000019c in main at /src/pico-examples/blink_simple/blink_simple.c:68breakpoint already hit 1 time4 hw watchpoint keep y *(uint32_t*)0x200096bc(gdb) rThe program being debugged has been started already.Start it from the beginning? (y or n) yStarting program: /src/pico-examples/build/blink_simple/blink_simple.elf target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00[New Thread 2]Thread 1 received signal SIGTRAP, Trace/breakpoint trap.data_cpy () at /src/pico-sdk/src/rp2_common/pico_crt0/crt0.S:470470 blo data_cpy_loop(gdb) bt#0 data_cpy () at /src/pico-sdk/src/rp2_common/pico_crt0/crt0.S:470#1 0x1000020e in hold_non_core0_in_bootrom () at /src/pico-sdk/src/rp2_common/pico_crt0/crt0.S:427Backtrace stopped: previous frame identical to this frame (corrupt stack?)(gdb) p malloc_mutex$5 = {core = {spin_lock = 0x0}, owner = -1 '\377'}(gdb) cContinuing.target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00Thread 1 received signal SIGTRAP, Trace/breakpoint trap.mutex_init (mtx=mtx@entry=0x200096bc <malloc_mutex>) at /src/pico-sdk/src/common/pico_sync/mutex.c:4545 mtx->owner = LOCK_INVALID_OWNER_ID;(gdb) bt#0 mutex_init (mtx=mtx@entry=0x200096bc <malloc_mutex>) at /src/pico-sdk/src/common/pico_sync/mutex.c:45#1 0x20000390 in runtime_init_mutex () at /src/pico-sdk/src/common/pico_sync/mutex.c:32#2 0x20000f62 in runtime_run_initializers_from (from=<optimized out>) at /src/pico-sdk/src/rp2_common/pico_runtime/runtime.c:26#3 0x20000f7c in runtime_run_initializers () at /src/pico-sdk/src/rp2_common/pico_runtime/runtime.c:32#4 0x20001fec in runtime_init () at /src/pico-sdk/src/rp2_common/pico_clib_interface/newlib_interface.c:192#5 0x10000222 in platform_entry () at /src/pico-sdk/src/rp2_common/pico_crt0/crt0.S:453Backtrace stopped: previous frame identical to this frame (corrupt stack?)(gdb) p malloc_mutex$6 = {core = {spin_lock = 0xd0000140}, owner = 0 '\000'}Hopefully someone more knowledgeable can explain this at a certain point - but it seems to me, for the time being this workaround works for RP2040 ...
Statistics: Posted by sdbbs — Sun May 04, 2025 6:44 pm