From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13463 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Question regarding dynamic loader Date: Wed, 21 Nov 2018 09:25:50 -0500 Message-ID: <20181121142550.GA23599@brightrain.aerifal.cx> References: 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 1542810240 20295 195.159.176.226 (21 Nov 2018 14:24:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 21 Nov 2018 14:24:00 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Gernot Reisinger To: musl@lists.openwall.com Original-X-From: musl-return-13479-gllmg-musl=m.gmane.org@lists.openwall.com Wed Nov 21 15:23:55 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 1gPTQ3-0005Cy-9y for gllmg-musl@m.gmane.org; Wed, 21 Nov 2018 15:23:55 +0100 Original-Received: (qmail 21513 invoked by uid 550); 21 Nov 2018 14:26:04 -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 20464 invoked from network); 21 Nov 2018 14:26:03 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:13463 Archived-At: On Wed, Nov 21, 2018 at 02:55:19PM +0100, Gernot Reisinger wrote: > Hi, > I recently stumbled upon an issue with preloading a shared object into a Go > application (see related Go ticket https://github.com/golang/go/issues/28909 > ). > > In short - Go comes with an internal linker which will not link crt code to > the application. The entry point will directly execute Go standard library > code. As musl libc calls shared object constructors in crt code, the shared I don't think this assessment of what musl does is correct. It calls the (initially loaded) shared object constructor via __libc_start_main. If the program is not entered via __libc_start_main, libc is not usable. Necessary initialization will have been bypassed. This has little to do with whether the crt code was linked, except that *crt1.o is normally responsible for calling __libc_start_main. If the linking process bypasses crt1, it needs to ensure that __libc_start_main ends up getting called in some other way. As far as I know this is also true for glibc, so I'm not sure why it differs. > objects constructors subsequently will never be invoked. Things will work > on glibc systems / processes. it It seems to be a subtle - but in this case > wide reaching - behavioral difference to glibc. > > I wonder if calling constructor functions from crt code is an intended musl > libc behavior. My personal - non expert - gut feeling considers glibc > behavior "more correct". Is there a chance that musl will change this > behavior? The musl behavior here is intentional. For FDPIC targets, it's impossible to run *any* application code, in the main application or shared libraries, before the main application's crt1 has executed, because there are (essentially -- the equivalent of) self-relocations performed at that stage that the dynamic linker can't see. If any ctors were invoked directly by the dynamic linker before passing control the the main application's entry point, they would run without these relocations in the main application having been performed, possibly resulting in runaway-wrong execution. I believe Go is doing some bad hacks here with regard to its C FFI, but it's likely fixable in some reasonable way. We should get more eyes looking at it. Rich