From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6361 Path: news.gmane.org!not-for-mail From: Michael Newsgroups: gmane.linux.lib.musl.general Subject: Re: gthread_once Date: Sat, 18 Oct 2014 13:16:52 +1100 Message-ID: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7ba97e702ad4c00505a91357 X-Trace: ger.gmane.org 1413598629 7072 80.91.229.3 (18 Oct 2014 02:17:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 18 Oct 2014 02:17:09 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6374-gllmg-musl=m.gmane.org@lists.openwall.com Sat Oct 18 04:17:05 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 1XfJZp-0005SF-1A for gllmg-musl@plane.gmane.org; Sat, 18 Oct 2014 04:17:05 +0200 Original-Received: (qmail 18069 invoked by uid 550); 18 Oct 2014 02:17:04 -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 18061 invoked from network); 18 Oct 2014 02:17:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=c4Mv4JZprZDr4/WRY49QA58sQWiGunS6xKZWsmToDNI=; b=dmPwO6DIiQ+IsTJbUhalP1fZMJT0IJebsF+0+zKwzM5RzubgdEnyINXYd+r22cS7JI d3X0Xy11idLH2nIPSgYCNvUfaeVQm5fSQ9y+mx7K2b+S/EGU6LUjtRj3FWLxtE9SgkUp Rc+7ahlyuZ+hRsRJOGxE/9W1KbGrMYMEV9UjFzj64Xddc/YCYYFfiEmcB6xzlfYzs5Fo 5VljiMmvZdmkMqOUa3/1XiiCQkbay8zN+UOOC37dYaJ65qM/zvGcfVd/0+QSylG3ZlWH qXzrCusBHvilCyuQpu00Q+IVxjDOroqeFy6Azrvp6Awg2mBrC+X7SEulASSgNAbtEPV0 TymA== X-Received: by 10.194.57.210 with SMTP id k18mr323426wjq.110.1413598612737; Fri, 17 Oct 2014 19:16:52 -0700 (PDT) Xref: news.gmane.org gmane.linux.lib.musl.general:6361 Archived-At: --047d7ba97e702ad4c00505a91357 Content-Type: text/plain; charset=UTF-8 Essentially my plan is to compile my console only app for android but using the musl library instead of bionic. Im compling for standard x86_64 linux first to see if its viable. My app is plain c++ using wxwidgets (base only) and boost threads/system. I compiled these dependencies using CC/CXX/AR etc vars set to x86_64-linux-musl-gcc etc... and they compile fine and appear to be only linking to musl libraries as i used -v on the compliation and watched the directories it pulls in. Could the pthread_once be something to do with this thread http://sourceware-org.1504.n7.nabble.com/PATCH-Provide-pthread-atfork-in-libc-nonshared-a-and-libc-a-td246012.html#a247866 Runing file against my binary is: ./vhui: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped If i run readelf -hld: ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: Advanced Micro Devices X86-64 Version: 0x1 Entry point address: 0x403309 Start of program headers: 64 (bytes into file) Start of section headers: 14776944 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 56 (bytes) Number of program headers: 4 Size of section headers: 64 (bytes) Number of section headers: 28 Section header string table index: 25 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000 0x0000000000417b4c 0x0000000000417b4c R E 200000 LOAD 0x0000000000417b50 0x0000000000a17b50 0x0000000000a17b50 0x0000000000014b98 0x0000000000037168 RW 200000 TLS 0x0000000000417b50 0x0000000000a17b50 0x0000000000a17b50 0x0000000000000000 0x0000000000000018 R 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RW 10 Section to Segment mapping: Segment Sections... 00 .init .text .fini .rodata .eh_frame .gcc_except_table 01 .ctors .dtors .jcr .data.rel.ro .got .got.plt .data .bss 02 .tbss 03 There is no dynamic section in this file. ---------- Forwarded message ---------- > From: Rich Felker > To: musl@lists.openwall.com > Cc: > Date: Fri, 17 Oct 2014 08:10:48 -0400 > Subject: Re: [musl] Re: gthread_once > 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 > > --047d7ba97e702ad4c00505a91357 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Essentially my plan is to compile my console onl= y app for android but using the musl library instead of bionic. Im compling= for standard x86_64 linux first to see if its viable. My app is plain c++ = using wxwidgets (base only) and boost threads/system. I compiled these depe= ndencies using CC/CXX/AR etc vars set to x86_64-linux-musl-gcc etc... and t= hey compile fine and appear to be only linking to musl libraries as i used = -v on the compliation and watched the directories it pulls in.


=
Runing file against my binary is:
./vhui: ELF 64-bit LSB =C2=A0ex= ecutable, x86-64, version 1 (SYSV), statically linked, not stripped

If i run readelf -hld:

= ELF Header:
=C2=A0 Magic: =C2=A0 7f 45 4c 46 02 01 01 00 00 00 00= 00 00 00 00 00=C2=A0
=C2=A0 Class: =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ELF64=
=C2=A0 Data: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02's complement, = little endian
=C2=A0 Version: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 (current)
=C2=A0 OS/ABI: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0UNIX - System V
=C2=A0 A= BI Version: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 0
=C2=A0 Type: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0EXEC (= Executable file)
=C2=A0 Machine: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Advanced Micro = Devices X86-64
=C2=A0 Version: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x1
=C2= =A0 Entry point address: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0= x403309
=C2=A0 Start of program headers: =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A064 (bytes into file)
=C2=A0 Start of section headers: = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A014776944 (bytes into file)
=C2= =A0 Flags: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x0
=C2=A0 Size of this header= : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 64 (bytes)
=C2= =A0 Size of program headers: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 56 (bytes)<= /div>
=C2=A0 Number of program headers: =C2=A0 =C2=A0 =C2=A0 =C2=A0 4
=C2=A0 Size of section headers: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= 64 (bytes)
=C2=A0 Number of section headers: =C2=A0 =C2=A0 =C2= =A0 =C2=A0 28
=C2=A0 Section header string table index: 25
<= div>
Program Headers:
=C2=A0 Type =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Offset =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 VirtAddr= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 PhysAddr
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0FileSiz =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0MemSiz =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Fla= gs =C2=A0Align
=C2=A0 LOAD =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x0= 000000000000000 0x0000000000400000 0x0000000000400000
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x0000000000417b4c 0x00= 00000000417b4c =C2=A0R E =C2=A0 =C2=A0200000
=C2=A0 LOAD =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x0000000000417b50 0x0000000000a17b50 0x0000000= 000a17b50
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A00x0000000000014b98 0x0000000000037168 =C2=A0RW =C2=A0 =C2=A0 200000<= /div>
=C2=A0 TLS =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x00000000004= 17b50 0x0000000000a17b50 0x0000000000a17b50
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x0000000000000000 0x0000000000000= 018 =C2=A0R =C2=A0 =C2=A0 =C2=A08
=C2=A0 GNU_STACK =C2=A0 =C2=A0 = =C2=A00x0000000000000000 0x0000000000000000 0x0000000000000000
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00x00000000000= 00000 0x0000000000000000 =C2=A0RW =C2=A0 =C2=A0 10

=C2=A0Section to Segment mapping:
=C2=A0 Segment Sections...
=C2=A0 =C2=A000 =C2=A0 =C2=A0 .init .text .fini .rodata .eh_frame .g= cc_except_table=C2=A0
=C2=A0 =C2=A001 =C2=A0 =C2=A0 .ctors .dtors= .jcr .data.rel.ro .got .got.plt .data .= bss=C2=A0
=C2=A0 =C2=A002 =C2=A0 =C2=A0 .tbss=C2=A0
=C2= =A0 =C2=A003 =C2=A0 =C2=A0=C2=A0

There is no dynam= ic section in this file.

---------- Forwarded m= essage ----------
From:=C2=A0Rich Felker <dalias@libc.org>
To:=C2=A0musl@lists.openwall.com=
Cc:=C2=A0
Date:=C2=A0Fri, 17 Oct 2014 08:10:48 -0400
Subject:=C2= =A0Re: [musl] Re: gthread_once
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 pthr= ead 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/0045= 25.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 th= e
> > 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 st= ill
> 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 o= f
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_onc= e
> function seems to be corrupted.

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

> Two fishy things:
>
>=C2=A0 =C2=A0- these are static inline functions, so to use this librar= y you have
>=C2=A0 =C2=A0 =C2=A0to use the same pthread implementation for all comp= ilations of
>=C2=A0 =C2=A0 =C2=A0application code. If anything in your tool chain go= es wrong, your
>=C2=A0 =C2=A0 =C2=A0screwed.
>
>=C2=A0 =C2=A0- right at the start it seems to rely on certain features = of the
>=C2=A0 =C2=A0 =C2=A0glibc 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 b= e
surprised that we haven't seen failures before.

Rich


--047d7ba97e702ad4c00505a91357--