From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6356 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: gthread_once Date: Fri, 17 Oct 2014 08:10:48 -0400 Message-ID: <20141017121048.GC32028@brightrain.aerifal.cx> References: <1413546143.5021.772.camel@eris.loria.fr> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1413547867 24013 80.91.229.3 (17 Oct 2014 12:11:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 17 Oct 2014 12:11:07 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6369-gllmg-musl=m.gmane.org@lists.openwall.com Fri Oct 17 14:11:03 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Xf6N3-0007to-Uh for gllmg-musl@plane.gmane.org; Fri, 17 Oct 2014 14:11:02 +0200 Original-Received: (qmail 29948 invoked by uid 550); 17 Oct 2014 12:11:01 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 29938 invoked from network); 17 Oct 2014 12:11:01 -0000 Content-Disposition: inline In-Reply-To: <1413546143.5021.772.camel@eris.loria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6356 Archived-At: 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