On Apr 3, 2013, at 4:30 PM, Jay Carlson wrote:

> In addition, touching errno means touching a TLS model symbol, and
> that's not supported in gcc 4.6. 

OK, that's starting to look like a bug.

At the toplevel .config, the default is CONFIG_TLS_SUPPORT off. This triggers 
toolchain/gcc/final/Makefile to insert "--disable-tls" into the gcc configure 
invocation.

uClibc is pretty unhappy about this. $build_dir/uClibc/Rules.mak has this 
little stanza:

==== snipped a little ====
# Test for TLS if NPTL support was selected.
GCC_HAS_TLS=$(shell \
        echo "extern __thread int foo;" | $(CC) -o /dev/null -S -xc - 2>&1)
ifneq ($(GCC_HAS_TLS),)
gcc_tls_test_fail:
        @echo "#### Your compiler does not support TLS and you are trying to 
build uClibc";
        @echo "#### with NPTL support. Upgrade your binutils and gcc to 
versions which";
        @echo "#### support TLS for your architecture. Do not contact uClibc 
maintainers";
        @echo "#### about this problem.";
        @exit 1;
endif
====

So why isn't that triggering if we turned TLS off? 
https://dev.openwrt.org/changeset/20018/ , which makes it clear that 
--disable-tls is only applicable to *gcc-final*, not the intermediate gcc used 
to build uClibc.

I'm not sure what the intent of CONFIG_TLS_SUPPORT is. Right now, regardless of 
how it's set, you will get a uClibc shared library containing TLS relocations 
and use of the architecture-specific find-my-thread instructions. 

root@OpenWrt:/lib# objdump -R libuClibc-0.9.33.2.so  | grep TLS
00066c9c R_MIPS_TLS_TPREL32  *ABS*
00066ca0 R_MIPS_TLS_TPREL32  *ABS*
00066ca4 R_MIPS_TLS_TPREL32  *ABS*
00066ca8 R_MIPS_TLS_DTPMOD32  *ABS*
00066cb0 R_MIPS_TLS_TPREL32  *ABS*

...and of course you get a NPTL libpthread.so filled with it, externally 
visible through errno and h_errno. All the config option seems to do is ban 
non-uClibc code from using __thread. Which might be the point, I don't know. Is 
NPTL the only viable pthread implementation these days?

Jay


_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Reply via email to