From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12258 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 11:04:33 +0000 Message-ID: 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> ,<20171219010830.GQ1627@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 1513681379 30699 195.159.176.226 (19 Dec 2017 11:02:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 19 Dec 2017 11:02:59 +0000 (UTC) To: "musl@lists.openwall.com" Original-X-From: musl-return-12274-gllmg-musl=m.gmane.org@lists.openwall.com Tue Dec 19 12:02:55 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 1eRFfh-0007dS-8W for gllmg-musl@m.gmane.org; Tue, 19 Dec 2017 12:02:53 +0100 Original-Received: (qmail 20084 invoked by uid 550); 19 Dec 2017 11:04:52 -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 20054 invoked from network); 19 Dec 2017 11:04:51 -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=XMgtvbXWyRyK4jbVbauM+afoSpyJUvIbfux1dJNwOWM=; b=ART0SzhvzNPr11ucmcxjGGSRqSvrsPYjLuYtHu4tlxMHCdI3YJ2UkHvBgV4uvobI+7yWQqyXBppnVHCxIHbvXLscgAzOoyY63UoMSf/TUteF7eHWupjcrn4RM/GGlvn60JtWuz7C5mEflh2WcTOcI8Zj6K3+Q+cyfUH4beQWJbU= Thread-Topic: [musl] [PATCH] split __libc_start_main.c into two files (Wasm) Thread-Index: AQHTb2pBP8VsOCdulkepcQ6wgWaD9qM4G+cAgAu9DICAAHLZ/4AAFzSAgAAC5HOAAE48gIAAAoPOgAAGuoCAAUMpeIAD7GkAgACPn2c= In-Reply-To: <20171219010830.GQ1627@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;VI1PR0502MB3888;6:vsKj9hW17MHWPrZBZcL7d4a0RQc1KcXgfcP9Qrh63O3n+RPIKtODWvp5iv6A+bPlV2s2/thWjfF4At8z9JLfzFS7d2kO1Kesw/UUXJLhmPMo19dypTGJaXaYmch9r0NyxSk9jgrCu3Hj85LlDInPE2AVElfeBayklZTqcVC+GGGVUzRjDia+mfZe1Ho3pQNq3pLAaUs1fmL4xQ7Yu1oFOqv/Okvsrl77/1rfreyJExsSOdo30VV7UaZHI98fu6dW/oxNmqiwduCBMfvME6tfLiXrALRpBWf7Q3MpDZci+ZoZx9xvYqa3h3dq/7WKbKAxiVNFUvkHbK907uQD1/YkQh/+udxMY6skM8H4oILc124=;5:wRaidgWTOE/028JKMisNJiRO8McTUjhT6kj99TU9+DsdTGkr9QZorFQeZV4FKdVVNiJ6mNrPG4u/BVIcoXKnwoDJZIGKuztzow1TcvMhf9qO+Z6cBiBbb0MV3Jpve/RZk8cRDeenMPtCRsQdVdcUEfMdkYRI2Zp7ZEIPMSUsS8I=;24:+IWUmr2/+8zSuTMDlG7Ks0Msta/jhdpW/mOq5riA4u+jf/J5HaXC+RlCfxc+05JeQZ2d+fXw06OuX/BphEznzQGpjVko+pvkQbrR+0lTyWc=;7:XMABj0iRw7lxsc8i/Kim+h5GjLEBfNwufQOiZKb9wB3E+vsyjINOdKayhwZdPIxIVxpeUKw83Jz/Rp5Lh5wqBKCP8bFn Zcl6OU1mkq1geLgyJ4xJjzVUAuj7yin2efgYuOxhiuUzvzWvd7MLhK6PAQUecWg/yw/rqgIRLMEYMBR3F7xNlcR943IlOl9Pal x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 5d496ae2-4be8-4162-0eba-08d546d048ec x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(5600026)(4604075)(4534020)(4602075)(4603075)(4627115)(201702281549075)(2017052603307);SRVR:VI1PR0502MB3888; x-ms-traffictypediagnostic: VI1PR0502MB3888: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(192374486261705)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040450)(2401047)(8121501046)(5005006)(3231023)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123555025)(20161123558100)(2016111802025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123562025)(6072148)(6043046)(201708071742011);SRVR:VI1PR0502MB3888;BCL:0;PCL:0;RULEID:(100000803101)(100110400095);SRVR:VI1PR0502MB3888; x-forefront-prvs: 052670E5A4 x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(396003)(376002)(366004)(39850400004)(346002)(52314003)(24454002)(189003)(199004)(6916009)(316002)(25786009)(105586002)(305945005)(5660300001)(5250100002)(2501003)(97736004)(14454004)(59450400001)(74316002)(7736002)(53936002)(6506007)(53546011)(478600001)(966005)(93886005)(86362001)(106356001)(3280700002)(68736007)(102836003)(76176011)(7696005)(6116002)(229853002)(2950100002)(3660700001)(33656002)(9686003)(6246003)(5640700003)(6306002)(99286004)(55016002)(2900100001)(6436002)(2351001)(1730700003)(81166006)(81156014)(2906002)(8936002)(8676002);DIR:OUT;SFP:1101;SCL:1;SRVR:VI1PR0502MB3888;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: 5d496ae2-4be8-4162-0eba-08d546d048ec X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2017 11:04:33.1489 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9ad766d3-c6a5-4458-8c58-244e7c118728 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0502MB3888 X-OriginatorOrg: realvnc.com Xref: news.gmane.org gmane.linux.lib.musl.general:12258 Archived-At: On 19 December 2017 01:08, Rich Felker wrote: > 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". There are two ELF-specific bits to __libc_start_main: 1) The first thing is that it calls main and exit! Wasm users don't want to= call exit. (This is different from the discussion we had before as to whet= her it's OK to *link in* exit when it's never called. This is about whether= it's actually OK to call exit.) exit destroys C++ global variables, and Wa= sm users don't want that. We need to able to call into the Wasm module repe= atedly from a JavaScript web page. Maybe think of a Wasm (statically-linked) binary as being a bit more like a= shared library: instead of exporting a single "entrypoint" for the kernel = to run (like a Unix process), it exports a list of functions for the JavaSc= ript environment to run repeatedly. We're not using the language of "shared= library" though, because we're using that terminology to mean Wasm librari= es calling each other, and we don't have all the tooling in place for that = in web browsers yet. 2) This second point is just for your interest. It doesn't affect the rest = of Musl, since Wasm can provide its own crt/wasm/crt1.c. (See: https://git= hub.com/NWilson/musl/blob/musl-wasm-native/crt/wasm/crt1.c) Another difference is that __libc_start_init uses the __init_array_start/en= d symbols, which come from special compiler-provided crtbegin.o/crtend.o ob= jects on ELF platforms. The linker has to arrange for a table of function p= ointers for Musl to call, and it does that using the magic .init_array ELF = section (plus some priority fiddling). In Wasm, most functions are not callable by pointer: a function pointer is = only assigned to code that has its address taken. For security, a decision = was taken *not* to use a table of function pointers for the startup code, s= ince that would mean taking the address of those functions, and they otherw= ise would be unlikely to need to go in the function pointer table. It's a h= ardening measure, to reduce the number of functions that can be used as the= target of an indirect call. Hence, the linker synthesises the init-function as a list of call-instructi= ons, rather than synthesising a list of function pointers for a pre-written= function to iterate over. This decision wasn't mine, but I'm sympathetic to it. We did discuss whethe= r it would be unhelpful to diverge from ELF like this, but the consensus wa= s that keeping the table of function pointers small was more worthwhile. Note - I realise that we could override the ELF-y __libc_start_init since i= t's weak. 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 s= tart mechanism. > It does require a pointer to the args/environment > formatted as an array of: > ... > but __init_libc and other code in musl also requires such an array to > be present. Yes, I've got an array of argv/envp for keeping __init_libc happy. That's O= K, that's an ELF convention that we're quite happy to follow to reduce fric= tion with Musl. In general, where possible I don't have a problem with emul= ating ELF. Thanks for your patience and for asking questions. I hope the answers help! Nick=