Hi Waldemar,
On Mon, 2015-09-14 at 06:52 +0200, Waldemar Brodkorb wrote:
...
Does this happen only when uClibc itself is compiled with stack
protection? Or just when the pthread app is statically linked and
compiled with -fstack-protector?
This only happen when libpthread.a is compiled with stack protection and
the binary is statically linked. I have tried compiling the app both
with and without -fstack-protector-all but that doesn't change the
behavior. A libpthread.a not compiled with stack protection also does
not show this behavior.
With uClibc
0.9.33.x the same thing happens. With glibc the program
works.
I can reproduce the bug. Moving __libc_setup_tls from NPTL init to
__uClibc_main.c fixes it. Why do you think it is ugly to do this?
With my patch __libc_setup_tls() was called twice. I also haven't
thought it through if if is ok to simply move it from the pthread code
or if something else is depending on it being there.
Does attached patch works for you? Just a cleaned up
version of your
fix. It doesn't produce any regressions running the testsuite.
Yes, that patch works just fine. I have tested it on my limited test
case as well as in the environment where I first encountered the bug.
Thanks and best regards,
Daniel Fahlgren