Fix: tls-compat multi-lib conflict
When configured with the TLS pthread key fallback either:
- explicitly with ./configure --disable-compiler-tls,
- or if compiler TLS is not usable,
(this can be confirmed by looking at the configure output:
Thread Local Storage (TLS): pthread_getspecific().)
There is an issue when using multiple flavors of RCU within the same
program. Unit tests concerned:
tests/unit/test_urcu_multiflavor
tests/unit/test_urcu_multiflavor_dynlink
Vladimir Nikulichev noticed crashes when using this setup. The problem
can be pinpointed to a missing macro expansion in urcu/tls-compat.h:
looking at the output of
nm tests/unit/.libs/test_urcu_multiflavor :
U __tls_access_rcu_reader
this seems to be the issue. We're missing macro expansion in
tls-compat.h. With this commit, it becomes:
U __tls_access_rcu_reader_bp
U __tls_access_rcu_reader_mb
U __tls_access_rcu_reader_memb
U __tls_access_rcu_reader_sig
Please note that this affects an unusual configuration of userspace RCU
(with TLS pthread key fallback), needed for some BSD that don't support
compiler TLS. Strictly speaking, this requires bumping the URCU library
soname version major number, because it breaks the ABI presented to
applications on those unusual configurations.
A following commit will handle the ABI migration: for stable releases
(stable-0.7 and stable-0.8 branches), the ABI is kept compatible, and
bogus usage are detected. For the upcoming stable-0.9, the soname will
simply be bumped.
Reported-by: Vladimir Nikulichev <nvs@tbricks.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
This page took 0.027681 seconds and 4 git commands to generate.