valgrind: enabls tls support
PATCH 1/1 valgrind: enabls tls support
Tested with example program from [1] with qemu_x86_64.
[1] http://valgrind.10908.n7.nabble.com/Thread-local-storage-TLS-support-td40815.html
--- package/valgrind/valgrind.mk | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
package/valgrind/valgrind.mk +7 -1
@@ -9,12 +9,18 @@ VALGRIND_SITE = http://valgrind.org/downloads VALGRIND_SOURCE = valgrind-$(VALGRIND_VERSION).tar.bz2 VALGRIND_LICENSE = GPLv2 GFDLv1.2 VALGRIND_LICENSE_FILES = COPYING COPYING.DOCS -VALGRIND_CONF_OPTS = --disable-tls --disable-ubsan +VALGRIND_CONF_OPTS = --disable-ubsan VALGRIND_INSTALL_STAGING = YES # patch touching configure.ac VALGRIND_AUTORECONF = YES +ifeq ($(BR2_GCC_ENABLE_TLS),y) +VALGRIND_CONF_OPTS += --enable-tls +else +VALGRIND_CONF_OPTS += --disable-tls +endif + # When Valgrind detects a 32-bit MIPS architecture, it forcibly adds # -march=mips32 to CFLAGS; when it detects a 64-bit MIPS architecture, # it forcibly adds -march=mips64. This causes Valgrind to be built
Signature · 1 line
2.1.4
PATCH 1/1 valgrind: enabls tls support
Dear Peter Seiderer,
Quoted 8 lines · Peter Seiderer
Tested with example program from [1] with
qemu_x86_64.[1] http://valgrind.10908.n7.nabble.com/Thread-local-storage-TLS-support-td40815.html
Signed-off-by Peter Seiderer <[email protected]>--- package/valgrind/valgrind.mk | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
I've applied your patch (after fixing the typo in the commit title).
However, it is not a fully correct solution: BR2_GCC_ENABLE_TLS is only valid for internal toolchains. For external toolchains, it will always be false, so you will never have TLS support enabled for external toolchains. I think it would really be easier if Valgrind had a compile-time way of determining whether TLS support is available or not, because it is the only package for which we need to know if TLS support is available or not.
I've nonetheless applied your patch because it doesn't make things really worse than they are. But I would really prefer if you could do some research at adjusting valgrind configure.ac to check TLS availability at compile time.
Generally speaking, I think we should drop BR2_GCC_ENABLE_TLS altogether, and simply enable TLS whenever we have NPTL threads being used.
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 valgrind: enabls tls support
Hello Thomas,
Quoted 5 lines · Thomas Petazzoni
Dear Peter Seiderer,
Quoted 2 lines · Peter Seiderer
Tested with example program from [1] with
qemu_x86_64.
Quoted 9 lines
Quoted 6 lines
[1] http://valgrind.10908.n7.nabble.com/Thread-local-storage-TLS-support-td40815.html
Signed-off-by Peter Seiderer <[email protected]>--- package/valgrind/valgrind.mk | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)I've applied your patch (after fixing the typo in the commit title).
Many thanks for fixing it...
Quoted 4 lines
However, it is not a fully correct solution:
BR2_GCC_ENABLE_TLSis only valid for internal toolchains. For external toolchains, it will always be false, so you will never have TLS support enabled for external toolchains. I think it would really be easier if Valgrind had a
I can live with it.... ;-)
Quoted 9 lines
compile-time way of determining whether TLS support is available or not, because it is the only package for which we need to know if TLS support is available or not.
I've nonetheless applied your patch because it doesn't make things really worse than they are. But I would really prefer if you could do some research at adjusting valgrind configure.ac to check TLS availability at compile time.
O.k, I will take a look...
Regards,
Peter
Quoted 7 lines
Generally speaking, I think we should drop
BR2_GCC_ENABLE_TLSaltogether, and simply enable TLS whenever we have NPTL threads being used.Best regards,
Thomas