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

Mathieu Desnoyers mathieu.desnoyers at efficios.com
Mon Apr 19 11:54:37 EDT 2021

----- On Apr 19, 2021, at 11:41 AM, Duncan Sands baldrick at free.fr wrote:

> 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.

Considering that rcu_dereference is public API, we would have to wait until we
do a major soname ABI bump _and_ an API break to do that, which I am very
reluctant to do, especially for the API break part.



Mathieu Desnoyers
EfficiOS Inc.

More information about the lttng-dev mailing list