From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13462 Path: news.gmane.org!.POSTED!not-for-mail From: Gernot Reisinger Newsgroups: gmane.linux.lib.musl.general Subject: Question regarding dynamic loader Date: Wed, 21 Nov 2018 14:55:19 +0100 Message-ID: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000f8f1ed057b2d1b60" X-Trace: blaine.gmane.org 1542808445 7357 195.159.176.226 (21 Nov 2018 13:54:05 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 21 Nov 2018 13:54:05 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-13478-gllmg-musl=m.gmane.org@lists.openwall.com Wed Nov 21 14:54:01 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 1gPSx7-0001mT-27 for gllmg-musl@m.gmane.org; Wed, 21 Nov 2018 14:54:01 +0100 Original-Received: (qmail 29957 invoked by uid 550); 21 Nov 2018 13:56:08 -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 29920 invoked from network); 21 Nov 2018 13:56:08 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=c7WBdcOt2iqB2TbFuNy5TDaDAcIAxoRqg07OkI3JbEI=; b=RByekcaKrJmA4PRvCdhcie+PXbQNG/xPe7Z2joBfFnmmoLuYw1BoSNJiMORIpTTe30 NAoTVUqEB/I7XS3/F5cl+tmX79vifar1rUFeaTaFx4qMVJ3JBfODDk0fo0T8zjeVhMhe KFehRiOBOstGBt6WCEdSq6hFeXOyCpFyqebr9/Ax6LonzrF2YxLej9hgqhmRrCWiCDjG v9A8wUfN5eL7+uxotM2NKOLRRFQMiKqGVZOZEpJs+fExm22lNMY/7DzCEa1ae8HftS3i m3ixoSzia8bzwGUFAvCKaXfpB1HZrGPEVhiicqdE5UW+E0Hcg/6kwVK/SNfzZLU8DPiC dwFw== X-Gm-Message-State: AA+aEWbkmNuPLNG4QLiKlgTkV/5Gz1tkR3FpAegqAEdsIYFjxVP/0Aze rQqO91HfnHVG4neKWcWiJSK86H/CmdddZNP+Dw/1z6I1 X-Google-Smtp-Source: AFSGD/WVQ2+tqG43zwCPeV/EnV9tHKSbyubVCAnKK6P+iX5p3syFGhiAO08PAnOIZD/YFDxqSY7EGDLHVxEEj6h4lTo= X-Received: by 2002:a2e:478f:: with SMTP id u137-v6mr4080138lja.142.1542808556595; Wed, 21 Nov 2018 05:55:56 -0800 (PST) Xref: news.gmane.org gmane.linux.lib.musl.general:13462 Archived-At: --000000000000f8f1ed057b2d1b60 Content-Type: text/plain; charset="UTF-8" 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 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? br Gernot --000000000000f8f1ed057b2d1b60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
I recently stumbled upon an issue= with preloading a shared object into a Go application (see related Go tick= et https://github.com= /golang/go/issues/28909).=C2=A0

In short - Go = comes with an internal linker which will not link crt code to the applicati= on. The entry point will directly execute Go standard library code. As musl= libc calls shared object constructors in crt code, the shared objects cons= tructors subsequently will never be invoked. Things will work on glibc syst= ems / processes. it It seems to be a subtle - but in this case wide reachin= g - behavioral difference to glibc.

I wonder if ca= lling constructor functions from crt code is an intended musl libc behavior= . My personal - non expert - gut feeling considers glibc behavior "mor= e correct". Is there a chance that musl will change this behavior?=C2= =A0
br
Gernot
--000000000000f8f1ed057b2d1b60-- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13464 Path: news.gmane.org!.POSTED!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: Question regarding dynamic loader Date: Wed, 21 Nov 2018 15:46:52 +0100 Message-ID: <20181121144652.GM21289@port70.net> 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 1542811500 24432 195.159.176.226 (21 Nov 2018 14:45:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 21 Nov 2018 14:45:00 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) Cc: Gernot Reisinger To: musl@lists.openwall.com Original-X-From: musl-return-13480-gllmg-musl=m.gmane.org@lists.openwall.com Wed Nov 21 15:44: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 1gPTkN-0006GA-9J for gllmg-musl@m.gmane.org; Wed, 21 Nov 2018 15:44:55 +0100 Original-Received: (qmail 3270 invoked by uid 550); 21 Nov 2018 14:47: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 3252 invoked from network); 21 Nov 2018 14:47:03 -0000 Mail-Followup-To: musl@lists.openwall.com, Gernot Reisinger Content-Disposition: inline In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:13464 Archived-At: * Gernot Reisinger [2018-11-21 14:55:19 +0100]: > 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 then calling into the c runtime later is undefined. crt is required for the c runtime setup. > code. As musl libc calls shared object constructors in crt code, the shared this is not true, the crt code is a tiny stub that calls the __libc_start_main setup code in libc.so, where ctors are run (there are several mechanisms to do ctors, but that's an elf thing: musl supports both _init and initarry style initializers, former is passed as argument to __libc_start_main the latter requires begin/end symbols for the .initarray section, in glibc is similar, but part of the initialization happens in the dynamic linker and part of it in libc_nonshared.a code which should be linked to the application and not in libc.so. static linking is another story but i assume you are using dynamic linking). > 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. this is libc internal implementation detail that callers should not try to guess or rely on. (however it has to be abi stable within one libc implementation because old crt1.o linked into an executable must work with new libc.so, otoh in glibc the abi can changed over time using symbol versioning for backward compatibility, and there were talks about doing exactly that because the way it runs ctor code is a perfect gadget for rop attacks and present in every executable) > 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 what made you think musl calls ctors from crt code? > behavior? > br > Gernot From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13468 Path: news.gmane.org!.POSTED!not-for-mail From: Gernot Reisinger Newsgroups: gmane.linux.lib.musl.general Subject: Re: Question regarding dynamic loader Date: Wed, 21 Nov 2018 16:52:53 +0100 Message-ID: References: <20181121142550.GA23599@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000746be2057b2ec057" X-Trace: blaine.gmane.org 1542815844 15496 195.159.176.226 (21 Nov 2018 15:57:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 21 Nov 2018 15:57:24 +0000 (UTC) Cc: musl@lists.openwall.com To: dalias@libc.org Original-X-From: musl-return-13484-gllmg-musl=m.gmane.org@lists.openwall.com Wed Nov 21 16:57:20 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 1gPUsS-0003ts-4b for gllmg-musl@m.gmane.org; Wed, 21 Nov 2018 16:57:20 +0100 Original-Received: (qmail 29937 invoked by uid 550); 21 Nov 2018 15:59:29 -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 24215 invoked from network); 21 Nov 2018 15:53:42 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MP1bJZZzucEmdeBqFEEdWVochlVn5RGCQh6psHwtBjE=; b=NbYMoqXSImootqpUYpIa7Jued813LsejGwcExmoNdavrV2cPeO38IcRfVNlM55+t/s aYpTyFXLiudG6vZ9OM8fw0MisFjm4AS506jK4qJNv9cZq0F8Kx8XBUpYGJcXwK+j9Vaf v+0PCp508ZPH/YT+6Mlf3rXEQY1s8n7SBY2JsUt7yp6MdehkeKB78z32mdu4lvqcOYRb TlJgJBzW+I6elvurlZSQC9FzsEBnPItFgq+tkREBNRrSXHLArGH0eEQLJtHQ20P885gc Yqlvh7ZiyDxNWJiqhPm4F5ah9ZsJQpsVgTabTXONR8xJhjex9ncDalmMjkZkWMPcEOmn hIoQ== X-Gm-Message-State: AA+aEWZm3leIFvU6a65sOfdGVcraeobFbcFRUazBcmDBi7mqULqyeP// VifYjRanw7SBxLetINumznM9uSimI4yaJY1BFabWyvCe X-Google-Smtp-Source: AFSGD/WuuYheMaD/CuSKDpz6XqP9C2RfXxoPzLHGXd3w9WmQlNpnYDkUDkJtB3EO6M2vmAnEuWxnplfkoSoQHsV9ybs= X-Received: by 2002:a2e:9bc3:: with SMTP id w3-v6mr4286565ljj.70.1542815611119; Wed, 21 Nov 2018 07:53:31 -0800 (PST) In-Reply-To: <20181121142550.GA23599@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:13468 Archived-At: --000000000000746be2057b2ec057 Content-Type: text/plain; charset="UTF-8" Thanks for your swift and extensive reply. Your explanations make a lot of sense. (sorry for my sloppy description - __libc_start_main invoked by *crt is the place where constructor calls happen as you did outline). I did no extensive research how glibc executes these constructor calls. At least the call stack indicates that they are partially executed in dynamic linker context - _dl_start_user () in /lib64/ld-linux-x86-64.so calling _dl_init. I will add a reference to reply to the Go ticket. Am Mi., 21. Nov. 2018 um 15:25 Uhr schrieb Rich Felker : > 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 > > --000000000000746be2057b2ec057 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for your swi= ft and extensive reply. Your explanations make a lot of sense. (sorry for m= y sloppy description - __libc_start_main invoked by *crt is the place where= constructor calls happen as you did outline).
I did no extensive= research how glibc executes these constructor calls. At least the call sta= ck indicates that they are partially executed in dynamic linker context - _= dl_start_user () in /lib64/ld-linux-x86-64.so calling=C2=A0_dl_init.

I will add a reference to reply to the Go ticket.=C2= =A0

= Am Mi., 21. Nov. 2018 um 15:25=C2=A0Uhr schrieb Rich Felker <dalias@libc.org>:
On Wed, Nov 21, 2018 at 02:55:19PM +0100, G= ernot 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 co= de to
> the application. The entry point will directly execute Go standard lib= rary
> code. As musl libc calls shared object constructors in crt code, the s= hared

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<= br> it differs.

> objects constructors subsequently will never be invoked. Things will w= ork
> 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<= br> > behavior "more correct". Is there a chance that musl will ch= ange 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<= br> 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

--000000000000746be2057b2ec057-- From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13470 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 11:14:00 -0500 Message-ID: <20181121161400.GC23599@brightrain.aerifal.cx> References: <20181121142550.GA23599@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 1542816730 21246 195.159.176.226 (21 Nov 2018 16:12:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 21 Nov 2018 16:12:10 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-13486-gllmg-musl=m.gmane.org@lists.openwall.com Wed Nov 21 17:12:06 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 1gPV6h-0005PH-VZ for gllmg-musl@m.gmane.org; Wed, 21 Nov 2018 17:12:04 +0100 Original-Received: (qmail 6058 invoked by uid 550); 21 Nov 2018 16:14:13 -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 6040 invoked from network); 21 Nov 2018 16:14:12 -0000 Content-Disposition: inline In-Reply-To: <20181121142550.GA23599@brightrain.aerifal.cx> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:13470 Archived-At: On Wed, Nov 21, 2018 at 09:25:50AM -0500, Rich Felker wrote: > On Wed, Nov 21, 2018 at 02:55:19PM +0100, Gernot Reisinger wrote: > > 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. For reference, this was initially done in commit c87a52103399135d2f57a91a8bcc749d8cb2ca83. Of course these code paths have changed significantly since then, but it gives some historical context. Rich From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13473 Path: news.gmane.org!.POSTED!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: Question regarding dynamic loader Date: Wed, 21 Nov 2018 17:41:56 +0100 Message-ID: <20181121164156.GP21289@port70.net> References: <20181121142550.GA23599@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 1542818408 29156 195.159.176.226 (21 Nov 2018 16:40:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 21 Nov 2018 16:40:08 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) Cc: dalias@libc.org, Gernot Reisinger To: musl@lists.openwall.com Original-X-From: musl-return-13489-gllmg-musl=m.gmane.org@lists.openwall.com Wed Nov 21 17:40:04 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 1gPVXm-0007P8-Ea for gllmg-musl@m.gmane.org; Wed, 21 Nov 2018 17:40:02 +0100 Original-Received: (qmail 24085 invoked by uid 550); 21 Nov 2018 16:42:08 -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 24067 invoked from network); 21 Nov 2018 16:42:08 -0000 Mail-Followup-To: musl@lists.openwall.com, dalias@libc.org, Gernot Reisinger Content-Disposition: inline In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:13473 Archived-At: * Gernot Reisinger [2018-11-21 16:52:53 +0100]: > I did no extensive research how glibc executes these constructor calls. At > least the call stack indicates that they are partially executed in dynamic > linker context - _dl_start_user () in /lib64/ld-linux-x86-64.so > calling _dl_init. the dynamic linker runs the - preinit_array functions of the main executable, - the init_array and DT_INIT functions of shared libraries. then via __libc_start_main the _init and init_array functions of the main executable are run by libc_nonshared.a code that is linked into the executable. so part of the initialization (main exe) does require entry via __libc_start_main (but this is not an issue for go). however this design can change when glibc introduces a new symbol version for __libc_start_main, so i don't see how go can rely on any of this. From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13474 Path: news.gmane.org!.POSTED!not-for-mail From: Florian Weimer Newsgroups: gmane.linux.lib.musl.general Subject: Re: Question regarding dynamic loader Date: Fri, 23 Nov 2018 10:29:40 +0100 Message-ID: <87lg5kw397.fsf@oldenburg.str.redhat.com> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1542965279 17091 195.159.176.226 (23 Nov 2018 09:27:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 23 Nov 2018 09:27:59 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) Cc: musl@lists.openwall.com To: Gernot Reisinger Original-X-From: musl-return-13490-gllmg-musl=m.gmane.org@lists.openwall.com Fri Nov 23 10:27:54 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 1gQ7kg-0004KX-KS for gllmg-musl@m.gmane.org; Fri, 23 Nov 2018 10:27:54 +0100 Original-Received: (qmail 20041 invoked by uid 550); 23 Nov 2018 09:30:02 -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 20020 invoked from network); 23 Nov 2018 09:30:01 -0000 In-Reply-To: (Gernot Reisinger's message of "Wed, 21 Nov 2018 14:55:19 +0100") X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.45]); Fri, 23 Nov 2018 09:29:49 +0000 (UTC) Xref: news.gmane.org gmane.linux.lib.musl.general:13474 Archived-At: * Gernot Reisinger: > 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). The bug here is that Go does not call __libc_start_main at all and does not link crt1.o. That is a major toolchain bug. It's surprising that this works at all. Thanks, Florian From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13475 Path: news.gmane.org!.POSTED!not-for-mail From: Gernot Reisinger Newsgroups: gmane.linux.lib.musl.general Subject: Re: Question regarding dynamic loader Date: Fri, 23 Nov 2018 12:34:17 +0100 Message-ID: References: <20181121142550.GA23599@brightrain.aerifal.cx> <20181121164156.GP21289@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000052da09057b535f43" X-Trace: blaine.gmane.org 1542972784 31565 195.159.176.226 (23 Nov 2018 11:33:04 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 23 Nov 2018 11:33:04 +0000 (UTC) To: musl@lists.openwall.com, dalias@libc.org Original-X-From: musl-return-13491-gllmg-musl=m.gmane.org@lists.openwall.com Fri Nov 23 12:33:00 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 1gQ9hi-00083C-LL for gllmg-musl@m.gmane.org; Fri, 23 Nov 2018 12:32:58 +0100 Original-Received: (qmail 20010 invoked by uid 550); 23 Nov 2018 11:35:07 -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 19992 invoked from network); 23 Nov 2018 11:35:07 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=00DfisonzhlM8LtISE6NxMnM3a9Y9zZSts+cfYW+Ut4=; b=AvDWpDsomBvgT42zSZNt8LTXHBf8NKdxBzN/kxVUh/zj1gFvkFolxR7UuKzbyVDCqb 2HIhnjagtu7/nakzz0sR/Zs1vQ3+b5+1T3kBK2rKpzCwQnJkl08LewVDkegrN49fJao4 EtMpUr8f0lso9D1NgtMS6INKm3++KzpUa955f5++J7+dP3ip/gvn103sCWQDJgHIAS/X C6PvJUftD2YCmSyjX2AEth9B1qrQYhQx0isOXtj73fbK7uFsNU+Afqi6WsSbI9exOhbm xuz50r+IX5QrdNMRkMX9S+KuWYDxgC1gSnHoA3BTm5Sjgz99vwwzDZjaur2Z65ruEzpr eRuw== X-Gm-Message-State: AA+aEWZrHo5D7ammWWC2ISwp9UUkjnuB26WIIwrg50PwhB8SSXVxJ0JM Q+k5kUH350y8TarMAn0DrqmSxpZAWOVmzaK03ZJocw== X-Google-Smtp-Source: AFSGD/VjStEJrCA7GTfoet++PdJEMuif0aRk6NFh4eb8BbAzMolQOW6/2gG/jGiUBA8Iz83eSXEN1FoZPXht+bW43Yc= X-Received: by 2002:a2e:478f:: with SMTP id u137-v6mr9633536lja.142.1542972895316; Fri, 23 Nov 2018 03:34:55 -0800 (PST) In-Reply-To: <20181121164156.GP21289@port70.net> Xref: news.gmane.org gmane.linux.lib.musl.general:13475 Archived-At: --00000000000052da09057b535f43 Content-Type: text/plain; charset="UTF-8" Thanks a lot for this exhaustive explanation - helps a lot to understand the different initialization stages. I agree, one should not assume a specific execution sequence of these initialization routines. Am Mi., 21. Nov. 2018 um 17:41 Uhr schrieb Szabolcs Nagy : > * Gernot Reisinger [2018-11-21 16:52:53 > +0100]: > > I did no extensive research how glibc executes these constructor calls. > At > > least the call stack indicates that they are partially executed in > dynamic > > linker context - _dl_start_user () in /lib64/ld-linux-x86-64.so > > calling _dl_init. > > the dynamic linker runs the > - preinit_array functions of the main executable, > - the init_array and DT_INIT functions of shared libraries. > > then via __libc_start_main the _init and init_array functions > of the main executable are run by libc_nonshared.a code that > is linked into the executable. > > so part of the initialization (main exe) does require entry > via __libc_start_main (but this is not an issue for go). > > however this design can change when glibc introduces a new > symbol version for __libc_start_main, so i don't see how > go can rely on any of this. > > --00000000000052da09057b535f43 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks a lot for this exhaustive explanation - helps a lot= to understand the different initialization stages. I agree, one should not= assume a specific execution sequence of these initialization routines.=C2= =A0


Am = Mi., 21. Nov. 2018 um 17:41=C2=A0Uhr schrieb Szabolcs Nagy <nsz@port70.net>:
* Gernot Reisinger <Gernot.Reisinger@omnino.at>= [2018-11-21 16:52:53 +0100]:
> I did no extensive research how glibc executes these constructor calls= . At
> least the call stack indicates that they are partially executed in dyn= amic
> linker context - _dl_start_user () in /lib64/ld-linux-x86-64.so
> calling _dl_init.

the dynamic linker runs the
- preinit_array functions of the main executable,
- the init_array and DT_INIT functions of shared libraries.

then via __libc_start_main the _init and init_array functions
of the main executable are run by libc_nonshared.a code that
is linked into the executable.

so part of the initialization (main exe) does require entry
via __libc_start_main (but this is not an issue for go).

however this design can change when glibc introduces a new
symbol version for __libc_start_main, so i don't see how
go can rely on any of this.

--00000000000052da09057b535f43--