[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALdjXpBo8GuUgi7W7iRNvUMOXGuO3H2Uek6dAxa_4cfb6uD38w@mail.gmail.com>
Date: Sat, 18 Oct 2014 13:16:52 +1100
From: Michael <msbroadf@...il.com>
To: musl@...ts.openwall.com
Subject: Re: gthread_once
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 <dalias@...c.org>
> To: musl@...ts.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
>
>
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
