From: Jens Gustedt <jens.gustedt@inria.fr>
To: musl@lists.openwall.com
Cc: Michael <msbroadf@gmail.com>
Subject: Re: Re: gthread_once
Date: Fri, 17 Oct 2014 13:42:23 +0200 [thread overview]
Message-ID: <1413546143.5021.772.camel@eris.loria.fr> (raw)
In-Reply-To: <CALdjXpDpWai8cuC28UyVe8dLjGS8J5WHyp8wjaNQvUmnctsGgA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1989 bytes --]
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 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.
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.
Jens
--
:: INRIA Nancy Grand Est ::: AlGorille ::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536 ::
:: :::::::::::::::::::::: gsm France : +33 651400183 ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2014-10-17 11:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-17 10:36 gthread_once Michael
2014-10-17 11:42 ` Jens Gustedt [this message]
2014-10-17 12:10 ` gthread_once Rich Felker
2014-10-18 2:16 gthread_once Michael
2014-10-18 10:18 ` gthread_once Szabolcs Nagy
2014-10-18 15:45 ` Rich Felker
2014-10-18 18:14 ` Szabolcs Nagy
2014-10-18 19:02 ` Rich Felker
2014-10-18 19:25 ` Jens Gustedt
2014-10-19 0:08 ` Michael
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1413546143.5021.772.camel@eris.loria.fr \
--to=jens.gustedt@inria.fr \
--cc=msbroadf@gmail.com \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).