[uclibc-ng-devel] problem with stack protection, threads and static binaries

Waldemar Brodkorb wbx at uclibc-ng.org
Thu Sep 17 20:02:31 CEST 2015


Hi Daniel,
Daniel Fahlgren wrote,

> 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.

I still get segfaults when using __UCLIBC_HAS_SSP__ while compiling
uClibc-ng and then use the results to statically link your test app
with -fstack-protector-all. Gdb shows:
(gdb) bt
#0  0x000000000040cf1b in _dl_aux_init ()

So it seems not completely solved, yet.
Any idea?

best regards
 Waldemar


More information about the devel mailing list