IssueTracker

     
    Instead of trying to redefine _LOCK_T in locks.c, which doesn't work 
    anymore after https://github.com/picolibc/picolibc/pull/825, define 
    __lock as k_mutex before including picolibc headers. 
     
    Remove (now) unnecessary casts to help validate that struct __lock 
    becomes struct k_mutex. 
     
    https://github.com/zephyrproject-rtos/zephyr/pull/87931 
     
    BUG=b:407595744 
    TEST=CQ 
     
    Change-Id: I08d6274db30286da615875613d67e1993611f51b 
    Signed-off-by: Jeremy Bettis <jbettis@google.com> 
    Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/zephyr/+/6418542 
    Auto-Submit: Jeremy Bettis <jbettis@chromium.org> 
    Tested-by: Jeremy Bettis <jbettis@chromium.org> 
    Reviewed-by: Jonathon Murphy <jpmurphy@google.com> 
    Commit-Queue: Jeremy Bettis <jbettis@chromium.org>

Files:

• M lib/libc/picolibc/locks.c
• M lib/libc/picolibc/picolibc-hooks.h

Hash: 60f39ccd91f90e651df0e79c99728c045e1664ba
Date:  Mon Mar 31 21:01:27 2025

     
    This reverts commit 60f39ccd91f90e651df0e79c99728c045e1664ba. 
     
    https://github.com/zephyrproject-rtos/zephyr/pull/87999 is a better fix. 
     
    BUG=b:407595744 
    TEST=CQ 
     
    Change-Id: I0e2592b20d7720d0733f895d456af10a8f1c927a 
    Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/zephyr/+/6427027 
    Commit-Queue: Jeremy Bettis <jbettis@chromium.org> 
    Reviewed-by: Al Semjonovs <asemjonovs@google.com> 
    Reviewed-by: Yuval Peress <peress@google.com> 
    Tested-by: Jeremy Bettis <jbettis@chromium.org>

Files:

• M lib/libc/picolibc/locks.c
• M lib/libc/picolibc/picolibc-hooks.h

Hash: 6284f7712af77c6a8e018e7de26e24892085301c
Date:  Wed Apr 2 16:23:56 2025

     
    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. 
     
    https://github.com/zephyrproject-rtos/zephyr/pull/87999 
     
    BUG=b:407595744 
    TEST=CQ 
     
    Change-Id: I3a72307049f9983b02d970a7335fbab30e1110d2 
    Signed-off-by: Keith Packard <keithp@keithp.com> 
    Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/zephyr/+/6427028 
    Reviewed-by: Al Semjonovs <asemjonovs@google.com> 
    Tested-by: Jeremy Bettis <jbettis@chromium.org> 
    Commit-Queue: Jeremy Bettis <jbettis@chromium.org> 
    Reviewed-by: Yuval Peress <peress@google.com>

Files:

• M lib/libc/picolibc/locks.c
• M lib/libc/picolibc/picolibc-hooks.h

Hash: 1966cd1a0c65dd7d3e10454c6f92f80161662c9e
Date:  Tue Apr 1 18:48:32 2025