From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12256 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] split __libc_start_main.c into two files (Wasm) Date: Mon, 18 Dec 2017 20:08:30 -0500 Message-ID: <20171219010830.GQ1627@brightrain.aerifal.cx> References: <20171207170356.GX1627@brightrain.aerifal.cx> <20171215041925.GG1627@brightrain.aerifal.cx> <20171215123331.GG15263@port70.net> <20171215172353.GL1627@brightrain.aerifal.cx> <20171215175657.GM1627@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 1513645610 7543 195.159.176.226 (19 Dec 2017 01:06:50 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 19 Dec 2017 01:06:50 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-12272-gllmg-musl=m.gmane.org@lists.openwall.com Tue Dec 19 02:06:46 2017 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 1eR6Mo-0001fv-DE for gllmg-musl@m.gmane.org; Tue, 19 Dec 2017 02:06:46 +0100 Original-Received: (qmail 9952 invoked by uid 550); 19 Dec 2017 01:08:45 -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 9931 invoked from network); 19 Dec 2017 01:08:44 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:12256 Archived-At: On Sat, Dec 16, 2017 at 01:21:39PM +0000, Nicholas Wilson wrote: > On 15 December 2017 17:56, Rich Felker wrote: > > Adding a new interface boundary/contract for a particular arch _is_ a > > big request, one of the biggest types. It's a permanent added > > constraint that has to be considered in future modifications to the > > code. Probably the only bigger type is adding a new public (to > > application) interface boundary/contract. > > Thanks for clarifying, I understand now. In our fork/branch, we will > have to call *something* on Wasm, since initialisation is different > to ELF and the default crt1.c doesn't really work for non-ELF archs. > > For your information, what we'll do is call __init_libc directly > from crt/wasm/crt1.c, since for the time being we need to do that to > keep the prototype working. It would be nice if that were to become > an accepted internal Musl interface, so that becomes "legal". > > (I have though reverted the split into two files of __libc_start_main.c.) I still don't see any good reason to call __init_libc instead of __libc_start_main. While the crt1 entry point (_start) itself is a not a normal C function but something specific to the ELF entry conventions, __libc_start_main is a perfectly good C function that is not "ELF specific". It does require a pointer to the args/environment formatted as an array of: { argc, argv[0], ..., argv[argc-1], 0, environ[0], ..., 0, auxv[0], ... 0 } but __init_libc and other code in musl also requires such an array to be present. I really don't think you're gaining anything by bypassing __libc_start_main, but you are losing the property of interfacing with a stable interface that will never change out from under you. Rich