In os_switch_seg_to_context() for aarchxx and riscv I noticed this comment and corresponding code:
/* On switching to app's TLS, we need put DR's TLS base into app's TLS
* at the same offset so it can be loaded on entering code cache.
* Otherwise, the context switch code on entering fcache will fault on
* accessing DR's TLS.
* The app's TLS slot value is stored into privlib's TLS slot for
* later restore on switching back to privlib's TLS.
*/
That looks off: I think that may be from an old flow in early aarch32 support where the hardware thread pointer was swapped while in the code cache. That seems fragile: we don't want to assume anything about the app's TLS layout (bad enough to depend on private library TLS layout). Today we keep the hardware tpid* register pointing to DR's TLS and mangle app reads of that register. We should go back to DR context before entering the cache, so I think this code needs to be cleaned up. I suspect it hasn't caused a problem because swapping to native and back only happens on Linux for the split init-start window in any supported usage. Although I'm now wondering about detach: is this happening on detach?
In os_switch_seg_to_context() for aarchxx and riscv I noticed this comment and corresponding code:
That looks off: I think that may be from an old flow in early aarch32 support where the hardware thread pointer was swapped while in the code cache. That seems fragile: we don't want to assume anything about the app's TLS layout (bad enough to depend on private library TLS layout). Today we keep the hardware tpid* register pointing to DR's TLS and mangle app reads of that register. We should go back to DR context before entering the cache, so I think this code needs to be cleaned up. I suspect it hasn't caused a problem because swapping to native and back only happens on Linux for the split init-start window in any supported usage. Although I'm now wondering about detach: is this happening on detach?