Disabling TLS address caching to help QEMU on GNU/Linux

2021-07-20 Thread Florian Weimer via Gcc
Currently, the GNU/Linux ABI does not really specify whether the thread pointer (the address of the TCB) may change at a function boundary. Traditionally, GCC assumes that the ABI allows caching addresses of thread-local variables across function calls. Such caching varies in aggressiveness betwe

Re: Disabling TLS address caching to help QEMU on GNU/Linux

2021-07-20 Thread Iain Sandoe via Gcc
Hi Florian, This also affects fibres implementations (both C++ and D ones at least from discussion with both communities). > On 20 Jul 2021, at 15:52, Florian Weimer via Gcc wrote: > > Currently, the GNU/Linux ABI does not really specify whether the thread > pointer (the address of the TCB) may

Re: Disabling TLS address caching to help QEMU on GNU/Linux

2021-07-21 Thread Thomas Huth via Gcc
On 20/07/2021 16.52, Florian Weimer wrote: Currently, the GNU/Linux ABI does not really specify whether the thread pointer (the address of the TCB) may change at a function boundary. [...] One important piece of software for GNU is QEMU (not just for GNU/Linux, Hurd development also benefits fr

Re: Disabling TLS address caching to help QEMU on GNU/Linux

2021-07-22 Thread Richard Biener via Gcc
On Tue, Jul 20, 2021 at 4:54 PM Florian Weimer via Gcc wrote: > > Currently, the GNU/Linux ABI does not really specify whether the thread > pointer (the address of the TCB) may change at a function boundary. > > Traditionally, GCC assumes that the ABI allows caching addresses of > thread-local var

Re: Disabling TLS address caching to help QEMU on GNU/Linux

2021-07-22 Thread Michael Matz
Hello, On Thu, 22 Jul 2021, Richard Biener via Gcc wrote: > But how does TLS usage transfer between threads? On the gimple level > the TLS pointer is not visible and thus we'd happily CSE its address: Yes. All take-address operations then need to be encoded explicitely with a non-CSE-able in