| 1354
|
|
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.
[1] https://stackoverflow.com/a/18067745
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: Ib43efa7674ecea99cec1c3fffae86829b44a97e5
|
Simon Marchi |
2 years ago
|
 |
|
| 1353
|
|
|
Mathieu Desnoyers |
2 years ago
|
|
|
| 1352
|
|
|
Mathieu Desnoyers |
2 years ago
|
|
|
| 1351
|
|
|
Mathieu Desnoyers |
2 years ago
|
|
|
| 1350
|
|
|
Mathieu Desnoyers |
2 years ago
|
|
|
| 1349
|
|
|
Mathieu Desnoyers |
2 years ago
|
|
|
| 1348
|
|
|
Michael Jeanson |
2 years ago
|
|
|
| 1347
|
|
bump SONAME major to 8
In URCU 0.11, we introduced new symbols to clean up the library symbol
namespacing, using the "alias" attribute to keep emitting the old
symbols, expecting to preserve ABI backward compatibility.
Unfortunately, it turns out that even though it works well for function
symbols, it is broken for public global variables due to the way ELF
copy relocation works.
When building a non-PIC executable that uses an extern variable, a .bss
symbol is emitted in the executable. This will take precedence over the
symbol implemented within the library in the Global Symbol Table.
Unfortunately, the alias within the library will not be aware that the
actual GST symbol differs from its alias within the library, and the
addresses for the symbol and its alias will differ at runtime.
Considering that this compatibility issue affects official library
releases, there is little we can do beyond documenting this issue, and
bumping the Userspace RCU major soname for the next (0.13) release.
Change-Id: I0ca8407dcffd871f025814923c6e329ec260133a
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
|
Michael Jeanson |
2 years ago
|
|
|
| 1346
|
|
|
Michael Jeanson |
2 years ago
|
|
|
| 1345
|
|
|
Michael Jeanson |
2 years ago
|
|
|
| 1344
|
|
|
Michael Jeanson |
3 years ago
|
|
|
| 1343
|
|
|
Michael Jeanson |
3 years ago
|
|
|
| 1342
|
|
|
Mathieu Desnoyers |
3 years ago
|
|
|
| 1341
|
|
|
Mathieu Desnoyers |
3 years ago
|
|
|
| 1340
|
|
|
Mathieu Desnoyers |
3 years ago
|
|
|
| 1339
|
|
|
Mathieu Desnoyers |
3 years ago
|
|
|
| 1338
|
|
|
Mathieu Desnoyers |
3 years ago
|
|
|
| 1337
|
|
|
Mathieu Desnoyers |
3 years ago
|
|
|
| 1336
|
|
|
Mathieu Desnoyers |
3 years ago
|
|
|
| 1335
|
|
|
Michael Jeanson |
3 years ago
|
|
|
collapse all