Make temporary variable in _rcu_dereference non-const
When building the lttng-tools project with Ubuntu's gcc 11, I get the
following error:
CC agent.lo
In file included from /tmp/lttng/include/urcu/arch.h:25, from /tmp/lttng/include/urcu/uatomic.h:23, from /home/simark/src/lttng-tools/src/bin/lttng-sessiond/agent.c:11:
/home/simark/src/lttng-tools/src/bin/lttng-sessiond/agent.c: In function ‘agent_update’:
/tmp/lttng/include/urcu/static/pointer.h:96:33: error: argument 2 of ‘__atomic_load’ discards ‘const’ qualifier [-Werror=incompatible-pointer-types]
96 | __atomic_load(&(p), &_________p1, __ATOMIC_CONSUME); \
| ^~~~~~~~~~~~~
/tmp/lttng/include/urcu/compiler.h:69:70: note: in definition of macro ‘caa_container_of’
69 | const __typeof__(((type *) NULL)->member) * __ptr = (ptr); \
| ^~~
/tmp/lttng/include/urcu/rculist.h:87:20: note: in expansion of macro ‘cds_list_entry’
87 | for (pos = cds_list_entry(rcu_dereference((head)->next), __typeof__(*(pos)), member); \
| ^~~~~~~~~~~~~~
/tmp/lttng/include/urcu/pointer.h:47:33: note: in expansion of macro ‘_rcu_dereference’
47 | #define rcu_dereference _rcu_dereference
| ^~~~~~~~~~~~~~~~
/tmp/lttng/include/urcu/rculist.h:87:35: note: in expansion of macro ‘rcu_dereference’
87 | for (pos = cds_list_entry(rcu_dereference((head)->next), __typeof__(*(pos)), member); \
| ^~~~~~~~~~~~~~~
/home/simark/src/lttng-tools/src/bin/lttng-sessiond/agent.c:1551:9: note: in expansion of macro ‘cds_list_for_each_entry_rcu’
1551 | cds_list_for_each_entry_rcu(ctx, &agt->app_ctx_list, list_node) {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
This is because the pointer passed to _rcu_dereference is const (the
pointer itself is const, IIUC, not necessarily the data it points to),
so the temporary _________p1 is also declared as const. We therefore
can't pass a non-const pointer to it to a function that modifies it.
I applied the trick found here [1] with success to get rid of the
constness of the variable. With this change, lttng-tools compiles
successfully with gcc 11.
There may be other spots in the headers where this would be needed, but
it is hard to spot them. I think we would need to write some test file
that pass const pointers to all macros of the API and see if they
compile.
Fix: x86 and s390 uatomic: __hp() macro warning with gcc 11
The __hp() macro used in the x86 and s390 uatomic code generates the
following warning with gcc-11:
In file included from ../include/urcu/uatomic.h:27, from ../include/urcu/static/wfcqueue.h:35, from ../include/urcu/wfcqueue.h:133, from workqueue.c:39:
workqueue.c: In function ‘workqueue_thread’:
../include/urcu/uatomic/x86.h:155:17: warning: array subscript ‘struct __uatomic_dummy[0]’ is partly outside array bounds of ‘struct cds_wfcq_tail[1]’ [-Warray-bounds]
155 | __asm__ __volatile__(
| ^~~~~~~
workqueue.c:184:38: note: while referencing ‘cbs_tmp_tail’
184 | struct cds_wfcq_tail cbs_tmp_tail;
| ^~~~~~~~~~~~
The (previously undocumented) reason for this macro is to allow passing the
"void *" parameter as "m" or "+m" operand to the inline assembly. That
motivation was explained in commit 53b8ed6836363 ("s390 uatomic arch fix").
The out of bound access is detected by gcc because struct
__uatomic_dummy's length is quite large: an array of 10 unsigned long,
which is larger than the size pointed to by the void pointer.
So rather than using a fixed-size type, cast to a structure containing
an array of characters of a size matching the @addr input argument.
While we are at it and digging out git archeology, properly document the
__hp() macro for posterity.
034a3ba...
by
Michael Jeanson <email address hidden>
fix: clock_gettime on macOs
Newer version of macOs have an implementation of clock_gettime() that
requires additionnal setup, move the platform specific code first so it
is always used.
Fix: rculist header: use parenthesis around macro parameters
The coding style followed across liburcu is to use parenthesis around
macro parameters when it would otherwise lead to unexpected results due
to priority of operators. Fix rculist.h to follow this coding style.
Fix: rcuhlist header: use parenthesis around macro parameters
The coding style followed across liburcu is to use parenthesis around
macro parameters when it would otherwise lead to unexpected results due
to priority of operators. Fix rcuhlist.h to follow this coding style.