From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12261 Path: news.gmane.org!.POSTED!not-for-mail From: Nicholas Wilson Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] split __libc_start_main.c into two files (Wasm) Date: Tue, 19 Dec 2017 17:46:22 +0000 Message-ID: References: <20171215041925.GG1627@brightrain.aerifal.cx> <20171215123331.GG15263@port70.net> <20171215172353.GL1627@brightrain.aerifal.cx> <20171215175657.GM1627@brightrain.aerifal.cx> <20171219010830.GQ1627@brightrain.aerifal.cx> ,<20171219155635.GS1627@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1513705487 3024 195.159.176.226 (19 Dec 2017 17:44:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 19 Dec 2017 17:44:47 +0000 (UTC) To: "musl@lists.openwall.com" Original-X-From: musl-return-12277-gllmg-musl=m.gmane.org@lists.openwall.com Tue Dec 19 18:44:43 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 1eRLwW-0000Gm-SG for gllmg-musl@m.gmane.org; Tue, 19 Dec 2017 18:44:41 +0100 Original-Received: (qmail 32250 invoked by uid 550); 19 Dec 2017 17:46:40 -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 32229 invoked from network); 19 Dec 2017 17:46:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=realvnc.onmicrosoft.com; s=selector1-realvnc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qR2xYtEMT5BWMyY22Vp41s+pIXLJLGAClLy8sS8gHWM=; b=C7cT1hW0W2mCWFuhhj4t20GPvk1PhKY6rXNlBxxPCe40Hx9zLsw4W15Oum/8/WXAj4fsLOX2v8f53+Ey/MvAF+BELcoVeKFnH85M4O3v8MAkdLc9nlPql/5sN0aqWd/PyBPx5CYPudq3Rk8zSpNOtwvgGaWD4O2C/h2wsfhFeoA= Thread-Topic: [musl] [PATCH] split __libc_start_main.c into two files (Wasm) Thread-Index: AQHTb2pBP8VsOCdulkepcQ6wgWaD9qM4G+cAgAu9DICAAHLZ/4AAFzSAgAAC5HOAAE48gIAAAoPOgAAGuoCAAUMpeIAD7GkAgACPn2eAAGiBgIAAEfB6 In-Reply-To: <20171219155635.GS1627@brightrain.aerifal.cx> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2a02:390:a001:192:d6be:d9ff:fe9c:1892] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;VI1PR0502MB3886;6:Pd2nhQ2tyzuApL9sDxZdQahDu9YOFQNVW+Wp2C4I2guWgFM84m4v24uiEPI8MlqtUPCL7KDMwR9MV76yuTzB+Kk3+MoIBPtSq+jKqSUG+yIhE/aIuPbtEvNQJBlHUBoKmFLNMNQGJOzA4d/iCoe8N8daiInaxi3irEpDVxfThIH64szdsu1RWaZctoY1oM9A9QDfFUPWZqrlKAKKFZ5q33Pf/3BIyz48M5rEQGLPmqjVrtRpLBy7tiAzxWcM7EA/9nOuzB0BPMDxULzpHwKAG/CZjskc2yUycDSUfMKSD/ah5YiAWJM8zZVlq0moFBWH/lrEYgH4Y31sdhAD8923sDmXKLWCVKySHcdrMdJdjOk=;5:kpOxcssWEKamVdLxdySjprXoUoKRElP4SGZRTaCc/0cTqn2F1XNi6PPKSkHxAqHMBXSxWE/5kG07U4n5Mum9VV30NNiZhkzWNLcsxqNM0L05We+Q88lCo2iPaqbMdKweINdGy3ShRXe1I7iDsBBVU2iuVw8aO7Qbqkl5fRNTKjM=;24:+0XMxDlQLDxZHvNG3AK7T8Rhe51P3FZyIJZKxRmqHlxJFO/kngTm0yvm4F6wA7XxtOtWPkbr6ojNHw5Akjit37VWJhpNmh9G2njfDMfXiZ0=;7:a93mhPBg9GGnqWyJs5tuFnJHxbktgbz5we+Bb02lc3g25Lqs7mUAqoFGtgZ3NNN10WU0/0aXQQ16RTC2I9cQEKfNyqqS AV2BSS4mBMP2A1+XPdRpq8WyTXm8+zHyPK3yWHtp13pTZS4pxZ+qmOpBqwQ25CVOJUVXTeF6BHJsFNaSX/EJmZb/ymykCNUPn4 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: efef760c-f5c9-422b-7e7b-08d547086b7a x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(5600026)(4604075)(4534020)(4602075)(4603075)(4627115)(201702281549075)(2017052603307);SRVR:VI1PR0502MB3886; x-ms-traffictypediagnostic: VI1PR0502MB3886: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231023)(6041248)(20161123560025)(20161123562025)(2016111802025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123558100)(6072148)(6043046)(201708071742011);SRVR:VI1PR0502MB3886;BCL:0;PCL:0;RULEID:(100000803101)(100110400095);SRVR:VI1PR0502MB3886; x-forefront-prvs: 052670E5A4 x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(396003)(39850400004)(346002)(376002)(366004)(24454002)(52314003)(189003)(199004)(7696005)(3280700002)(2906002)(76176011)(81156014)(33656002)(8676002)(1730700003)(86362001)(68736007)(6506007)(53546011)(305945005)(105586002)(106356001)(74316002)(5250100002)(3660700001)(99286004)(59450400001)(2351001)(7736002)(2501003)(6436002)(478600001)(5640700003)(55016002)(229853002)(6246003)(53936002)(9686003)(14454004)(25786009)(97736004)(316002)(102836003)(93886005)(8936002)(81166006)(2900100001)(2950100002)(6916009)(6116002)(5660300001);DIR:OUT;SFP:1101;SCL:1;SRVR:VI1PR0502MB3886;H:VI1PR0502MB3885.eurprd05.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; received-spf: None (protection.outlook.com: realvnc.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=nicholas.wilson@realvnc.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM X-MS-Exchange-CrossTenant-Network-Message-Id: efef760c-f5c9-422b-7e7b-08d547086b7a X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2017 17:46:22.9418 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9ad766d3-c6a5-4458-8c58-244e7c118728 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0502MB3886 X-OriginatorOrg: realvnc.com Xref: news.gmane.org gmane.linux.lib.musl.general:12261 Archived-At: On 19 December 2017 15:56, Rich Felker wrote: > This is not ELF-specific, and it's not different from the discussion > we had before. You seem to be under the impression that exit "gets > called" because __libc_start_main is called. This is not true. exit is > only called if main returns. (In fact, if you have LTO, the linker > will even optimize out exit like you wanted if main does not return.) >From our point of view, exit being called *is* a consequence of __libc_star= t_main. Everything must return; there's no way to hold up the JavaScript ma= in loop in a browser (unless you spin at 100% CPU and freeze the entire bro= wser page, which is totally unacceptable). Wasm is run in a single-threaded= asynchronous environment, really just like normal JavaScript, where every = function is non-blocking. (The difference between JavaScript and Wasm is that Wasm doesn't use the JS= heap, is guaranteed to generate no JS garbage, and is strongly-typed so ca= n be compiled to native x86/ARM code as soon as the browser receives it, so= it runs at the same speed as a native executable. A typical C function com= piled the "normal" way to a native C executable will have nearly identical = x86 assembly to the x86 code that a browser produces for the corresponding = Wasm function. Neat! But, it does mean no non-blocking functions, since the= JavaScript environment is not able to handle that. The JavaScript host env= ironment is event-driven: when I/O happens or some other event occurs, we'l= l call into the Wasm module again, and expect to return promptly so that th= e browser's event loop isn't blocked.) > As for why it's not ELF-specific, returning from main producing > behavior as if exit were called is part of the C language. Yes, I agree - main must call exit when it returns. But in Wasm we don't wa= nt main to get called at all - since immediately afterwards the Wasm module= becomes unusable for anything else (because of exit cleanup). For people w= ith one-shot applications, there will be provision for calling main if they= want it. However, I don't expect it to be common for people to use that fu= nctionality. >> However, given that we need to call __init_libc >> directly anyway, we may as well save some code and just register >> __init_libc with the Wasm start mechanism. > From my perspective, doing things in gratuitously arch-dependent ways > to "save some code" doesn't make sense when you're trading a small > (trivial relative size) amount of code for a permanent interface > boundary and maintenance burden. I mean, we have to call __init_libc directly anyway, so may as well just de= pend on a single internal interface, rather than using a second internal in= terface as well like __libc_start_init. By "short" I mean "use the absolute= minimum of internal Musl dependencies". Because of the requirement not to = call exit, I can't see a way of not calling *any* internal Musl functions, = so getting it down to just __init_libc is the least-intrusive we can be. Responding to Szabolcs: On 19 December 2017 15:27, Szabolcs Nagy wrote: > the correctness of the runtime is only guaranteed if you > go via the symbol __libc_start_main otherwise future > changes to that function can easily break your wasm port. Yes, we'll have to make sure each time we update our fork that it still wor= ks. That's acceptable to me, we understand that the dependency is purely in= ternal to libc, it's a not a public interface that Musl has to support fore= ver. I accept that as long as we have a fork, we risk having to do some mai= ntenance whenever we update to the latest Musl release. (But, with many peo= ple at Google and Mozilla working on Wasm long-term, I'm not worried that W= asm support will stagnate.) That's why I was hoping to eventually merge the Wasm support upstream, so t= hat changes to interfaces used internally within Musl can take Wasm into ac= count, rather than risk using internal interfaces without your knowledge. All the best, Nick=