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--