On Wed, 16 Feb 2022 at 20:28, Stefan Hajnoczi <stefa...@gmail.com> wrote: > > On Wed, 16 Feb 2022 at 18:14, Florian Weimer <fwei...@redhat.com> wrote: > > > > * Stefan Hajnoczi: > > > > > I've been trying to make the inline asm that gets the address of a TLS > > > variable for QEMU coroutines pass QEMU's GitLab CI. > > > https://gitlab.com/stefanha/qemu/-/blob/coroutine-tls-fix/include/qemu/coroutine-tls.h#L89 > > > > > > The code isn't -fPIC-friendly (R_X86_64_TPOFF32 relocations aren't > > > allowed in -fPIC shared libraries) so builds fail with ./configure > > > --enable-modules. While I was tackling this I stumbled on this: > > > > > > void *dst_ptr; > > > asm volatile("" : "=r"(dst_ptr) : "0"(&tls_var)) > > > > > > What's nice about it: > > > - It's portable, there are no arch-specific assembly instructions. > > > - It works for both -fPIC and non-PIC. > > > > > > However, I wonder if the compiler might reuse a register that already > > > contains the address. Then we'd have the coroutine problem again when > > > qemu_coroutine_yield() is called between the earlier address calculation > > > and the asm volatile statement. > > > > > > Thoughts? > > > > Sorry, I don't see why this isn't equivalent to a plain &tls_var. > > What exactly are you trying to achieve? > > &tls_var, except forcing the compiler to calculate the address from scratch. > > The goal is to avoid stale TLS variable addresses when a coroutine > yields in one thread and is resumed in another thread.
I'm basically asking whether the &tls_var input operand is treated as volatile and part of the inline assembly or whether it's just regular C code that the compiler may optimize with the surrounding function? Stefan
