Browse Source
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 <keithp@keithp.com>pull/89357/head
1 changed files with 17 additions and 7 deletions
Loading…
Reference in new issue