You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
libc/picolibc: Make lock typing match between Zephyr and picolibc
Picolibc's retargetable locking is based upon having the user own the lock
type (struct __lock, along with typedef struct __lock *_LOCK_T), and then
having the picolibc internal code only refer to this type via the _LOCK_T
pointer typedef, leaving the actual struct undeclared there.
Zephyr wants to use 'struct k_mutex' for this type; the initial picolibc
port handled this by trying to redefine the picolibc locking to use 'void
*' instead of 'struct __lock *' by including '#define _LOCK_T void
*'. Which 'works' as long as the Zephyr code doesn't actually include
picolibc's sys/lock.h.
A recent picolibc change to support POSIX stdio locking has picolibc's
stdio.h including sys/lock.h, which breaks Zephyr's hack.
To fix this, create a real 'struct __lock' type as
struct __lock { struct k_mutex m; };
Define all of the required picolibc locking API with this real type,
referring to the mutex inside without needing any casts.
This required switching the definition of the C library global lock from
K_MUTEX_DEFINE to the open-coded version, STRUCT_SECTION_ITERABLE_ALTERNATE
so that it has the correct type and still lands in the same elf section.
The only mildly inappropriate code left is that lock are allocated using
k_object_alloc(K_OBJ_MUTEX), which "works" because the size of 'struct
__lock` will exactly match the size of 'struct k_mutex' because of C's
struct allocation rules.
Signed-off-by: Keith Packard <[email protected]>
0 commit comments