[lttng-dev] liburcu: LTO breaking rcu_dereference on arm64 and possibly other architectures ?

[Duncan Sands]

Hi Mathieu,

On 4/19/21 5:31 PM, Mathieu Desnoyers wrote:
> ----- On Apr 19, 2021, at 5:41 AM, Duncan Sands baldrick at free.fr wrote:
> 
> 
>>
>>> Quick question: should we use __atomic_load() or atomic_load_explicit() (C) and
>>> (std::atomic<__typeof__(x)>)(x)).load() (C++) ?
>>
>> If both are available, is there any advantage to using the C++ version when
>> compiling C++?  As opposed to using the C11 one for both C and C++?
> 
> I recently noticed that using C11/C++11 atomic load explicit is not a good
> fit for rcu_dereference, because we want the type to be a pointer, not an
> _Atomic type. gcc appears to accept a looser typing, but clang has issues
> trying to build that code.

in the long run maybe the original variables should be declared with the 
appropriate atomic type from the get-go.

> So I plan to use __atomic(p, v, __ATOMIC_CONSUME) instead in both C and C++.
> 
> Also, I'll drop the cmm_smp_read_barrier_depends() when using __ATOMIC_CONSUME,
> because AFAIU their memory ordering semantics are redundant for rcu_dereference.

Yeah, keeping the barrier makes no sense in that case.

> 
> Here is the resulting commit for review on gerrit:
> 
> https://review.lttng.org/c/userspace-rcu/+/5455 Fix: use __atomic_load() rather than atomic load explicit [NEW]

Looks good to me (I didn't test it though).

Ciao, Duncan.