casaroli opened a new pull request, #20723:
URL: https://github.com/apache/nuttx/pull/20723

   ## Summary
   
   Two commits for thread-local storage in arm64 user code.
   
   1. User code found the TLS info of the running thread by rounding the stack 
pointer down. Code that runs on another stack (a context from `makecontext()`, 
a coroutine) got another address, and libc read garbage as its stream list, 
errno and pthread keys. The kernel now sets `TPIDR_EL0` of each thread to the 
base of its stack allocation, saves and restores it with the context, and user 
code reads it through `up_tls_info()`. A forked child gets its own value, a 
signal handler keeps the thread's value.
   2. A toolchain without native TLS (for example the Arm GNU toolchain for 
`aarch64-none-elf`) compiles `__thread` into calls to `__emutls_get_address()`, 
and that toolchain's libgcc keeps one copy per program. libc now provides 
`__emutls_get_address()` and `__emutls_register_common()` with one copy per 
thread, held by a pthread key and freed when the thread exits.
   
   ## Impact
   
   arm64 only. `__thread` variables are per thread, and TLS works on any stack.
   
   ## Testing
   
   Builds: `qemu-armv8a:nsh`, `qemu-armv8a:knsh`, `lm3s6965-ek:qemu-flat`.
   
   Runtime, QEMU 11 with HVF on an Apple M4: `ostest` on `qemu-armv8a:knsh` 
(kernel build) and `qemu-armv8a:nsh` (flat build) ends with `ostest_main: 
Exiting with status 0`.
   
   `tools/checkpatch.sh -c -u -m -g` passes.
   
   A 4-thread test of `__thread` variables on `qemu-armv8a:knsh` (Arm GNU 
Toolchain, emulated TLS): before, all threads read and wrote one copy of each 
variable; with the change each thread has its own. Code that runs on a stack 
from `makecontext()` read garbage as its TLS info and faulted in the kernel in 
its first `printf()`; with `TPIDR_EL0` it runs.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to