From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13417 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Problems with pthreads from a shared object? Date: Thu, 8 Nov 2018 12:37:29 -0500 Message-ID: <20181108173729.GB5150@brightrain.aerifal.cx> References: <20181107233142.GV5150@brightrain.aerifal.cx> <20181107234526.GW5150@brightrain.aerifal.cx> <20181108004312.GX5150@brightrain.aerifal.cx> <20181108151715.GA5150@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1541698541 29222 195.159.176.226 (8 Nov 2018 17:35:41 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 8 Nov 2018 17:35:41 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-13433-gllmg-musl=m.gmane.org@lists.openwall.com Thu Nov 08 18:35:37 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1gKoDN-0007O9-M0 for gllmg-musl@m.gmane.org; Thu, 08 Nov 2018 18:35:33 +0100 Original-Received: (qmail 30466 invoked by uid 550); 8 Nov 2018 17:37:42 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 30447 invoked from network); 8 Nov 2018 17:37:42 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:13417 Archived-At: On Thu, Nov 08, 2018 at 12:14:39PM -0500, Barry Flartus wrote: > > > > I think it would be helpful to understand what you're trying to do. > > > > Thanks for your help so far. Let me try and explain what I'm trying to > accomplish. I have a program that runs as an executable and uses pthreads. > I've compiled this program with musl statically with the end goal of it > being portable across older and newer systems. I want to also be able to > compile this program as a shared object so it may be loaded via dlopen() > inside of a glibc program. As mentioned previously, if I compile my shared > object with glibc, it loads via dlopen(). > > My lack of understanding is this: if I directly compile in musl's libc.a > (which contains its implementation of pthreads) into my shared object, > shouldn't it have the relevant pthreads functions compiled in, without > having runtime issues? That's what seems to work for my musl-compiled It has the right code for being able to run in a process where the (part of) libc inside your .so is the only libc in the process. It does not have the right code for interoperating with a different arbitrary libc in the same process where both of them rightly believe themselves the sole owner of various process-global or thread-global state. > static executable, so I'm trying to wrap my head around why it wouldn't > work for a shared object. In my case, I'm considering the shared object > just a different form-factor for the same program. Conceptually, the reasons it won't work are unbounded; any particular list could become incomplete with newer versions of musl and/or glibc. In practice, issues you would definitely face include but are not limited to: - Anything that depends on initialization at startup time will fail, as the musl __libc_start_main was never called. - Aside from a few fields which are compiler ABI, the content/layout of the thread structure is an implementation detail subject to change even between versions, and will not match between musl and glibc. This matters even if the glibc code is not starting threads since the main thread will have a glibc-format thread structure pointed to by its thread pointer (%fs:0 on x86_64) and any glibc functions called from your library will expect glibc-format thread structures (even if the thread was started by the musl pthread_create). - Assuming you didn't link with -Bsymbolic[-functions], calls to libc functions that were linked in your library may (will) get interposed by glibc functions already present, and the musl functions won't actually get called, except for the ones that don't exist in glibc (because they're in its librt or libpthread or something). And when some functions from musl which do end up getting called execute, they'll call a mix of glibc functions (when they reference something bu its public symbol) and musl functions (when they call musl-internal interfaces). These will be expecting/operaring on different and incompatible data structures. - If you did link with -Bsymbolic[-functions], you'd end up calling musl's malloc in the same process as glibc's malloc and they'd be fighting over ownership of the brk. Things would also blow up badly if a pointer returned by one's malloc was passed to the other's realloc/free at some point. - Many more things... Ultimately, it's *always* unsafe to have two libraries with conflicting interfaces linked into the same program, and even moreso when they're something as central (with ownership of central global state) as libc. Rich