Re: Re: gthread_once

[Rich Felker <dalias@libc.org>]

On Fri, Oct 17, 2014 at 01:42:23PM +0200, Jens Gustedt wrote:
> Hello,
> 
> Am Freitag, den 17.10.2014, 21:36 +1100 schrieb Michael:
> > I'm not linking to glibc. gthread is a thin wrapper over pthread used
> > by gcc (i.e https://gcc.gnu.org/onlinedocs/libstdc
> > ++/manual/ext_concurrency_impl.html).
> > 
> > 
> > It seems my problem is related to this:
> > 
> > 
> > http://www.riscos.info/pipermail/gcc/2008-July/004525.html
> > 
> > 
> > 
> > I have compiled g++ toolchain using musl-1.1.5
> > 
> > 
> > Is this a bug in musl or do i need to turn off the _GTHREAD in the
> > libstdc++ library?
> 
> If you are really sure that your whole toolchain is built with musl,
> things like that shouldn't happen. My guess would be that there still
> is some inconsistency somewhere and a glibc version of pthreads is
> loaded before musl. It could help if you'd compile your libraries with
> debugging symbols so we could see where (which function and which
> version) this happens.

This sounds unlikely. He's static linking, so there is no separate
loading of libraries, but even if there were, musl's dynamic linker
refuses to load a library named libpthread.*.

Still, I think it would be helpful to see some indication of whether
the binary is actually a static binary that was created correctly. The
output of the "file" utility run on it, and possibly the output of
readelf -hld or even full readelf -a (although the latter might reveal
a lot about the program and be big).

> This gthread stuff doesn't seem to be too complicated. It *should*
> just generate calls to the corresponding pthread functions, but
> obviously here for you it doesn't. Your stack in the __gthread_once
> function seems to be corrupted.

It looks like it called a function via a function pointer that
happened to be null.

> Two fishy things:
> 
>   - these are static inline functions, so to use this library you have
>     to use the same pthread implementation for all compilations of
>     application code. If anything in your tool chain goes wrong, your
>     screwed.
> 
>   - right at the start it seems to rely on certain features of the
>     glibc implementation concerning weak symbols.
> 
> This seems to be handled with the macros
> 
> __GXX_WEAK__ && _GLIBCXX_GTHREAD_USE_WEAK
> 
> It could be a starting point to see how they are set and to play at
> bit with them.

These sound problematic, but if there's something wrong here, I'd be
surprised that we haven't seen failures before.

Rich