qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC v2 1/4] tls: add macros for coroutine-safe TLS variables


From: Florian Weimer
Subject: Re: [RFC v2 1/4] tls: add macros for coroutine-safe TLS variables
Date: Thu, 02 Dec 2021 15:57:34 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

* Peter Maydell:

> On Thu, 2 Dec 2021 at 14:44, Peter Maydell <peter.maydell@linaro.org> wrote:
>> My compiler-developer colleagues present the following case where
>> 'noinline' is not sufficient for the compiler to definitely
>> use different values of the address-of-the-TLS-var across an
>> intervening function call:
>>
>>   __thread int i;
>>
>>   __attribute__((noinline)) long get_ptr_i()
>>   {
>>     return (long)&i;
>>   }
>>
>>   void switcher();
>>
>>   int g()
>>   {
>>     long a = get_ptr_i();
>>     switcher();
>>     return a == get_ptr_i();
>>   }
>>
>> Trunk clang optimizes the comparison of the two pointers down
>> to "must be always true" even though they might not be if the
>> switcher() function has resulted in a change-of-thread:
>>   https://godbolt.org/z/hd67zh6jW
>>
>> The 'optnone' attribute (clang-specific) seems to be able
>> to suppress this
>
> ...no it doesn't -- although the get_ptr_i() function is
> called both before and after, its return value is ignored
> and g() always still returns 'true'.

__attribute__ ((weak)) would mark get_ptr_i as interposable and should
act as an optimization barrier for any compiler.  Unless the compiler
defaults -fno-semantic-interposition *and* feels very, very strongly
about its meaning (clang 13 doesn't seem to, despite the
-fno-semantic-interposition default even with -fpic).

Thanks,
Florian




reply via email to

[Prev in Thread] Current Thread [Next in Thread]