From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12251 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: Fri, 15 Dec 2017 12:56:57 -0500 Message-ID: <20171215175657.GM1627@brightrain.aerifal.cx> References: <20171207170356.GX1627@brightrain.aerifal.cx> <20171215041925.GG1627@brightrain.aerifal.cx> <20171215123331.GG15263@port70.net> <20171215172353.GL1627@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 1513360629 26399 195.159.176.226 (15 Dec 2017 17:57:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 15 Dec 2017 17:57:09 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-12267-gllmg-musl=m.gmane.org@lists.openwall.com Fri Dec 15 18:57:05 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 1ePuEK-0006YD-Bv for gllmg-musl@m.gmane.org; Fri, 15 Dec 2017 18:57:04 +0100 Original-Received: (qmail 23794 invoked by uid 550); 15 Dec 2017 17:57:10 -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 23769 invoked from network); 15 Dec 2017 17:57:09 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:12251 Archived-At: On Fri, Dec 15, 2017 at 05:43:33PM +0000, Nicholas Wilson wrote: > On 15 December 2017 17:23, Rich Felker wrote: > > I don't see this as ugly at all -- the obvious behavior for exit is > > for it to just go into a "halted" state. > > There is no builtin lifecycle for that in web browsers, but we can emulate it. There's always a trivial halted state: for(;;); Presumably there are also more efficient ones. :-) > > This is what you generally > > expect on embedded C implementations with no OS, or if pid 1 exits on > > a unix-like system. If you don't yet support thread creation, all it > > has to do is something like for(;;) wait_for_something(); or similar. > > Once you have threads, you may need some nontrivial work to ensure > > that all threads enter a halted state, or it might just be as simple > > as stopping the interpreter. > > We certainly can't do an infinite loop (who wants tabs in their > browser to lock their CPU at 100%?) - and there's no way to wait on > anything in Wasm since it's single-threaded. Wait doesn't require a thread. It could be waiting for data from a source that will never have data, waiting for elapse of a certain period of time (e.g. for(;;) sleep(1000000000);), etc. > A trap is the only way to report to the interpreter that it should > stop execution. It's workable, although awkward. (JavaScript can > also throw exceptions, but Wasm code will soon be able to catch > those, so a trap is I believe the only uncatchable exceptional > condition.) > > It will look something like defining "__syscall_exit() { > __builtin_trap(); }" for Wasm. Sounds ok. > If you really don't want to split the translation unit, I can live > with it, although it doesn't seem like a big request, since it's not > changing the code at all, just giving independent linkage to two > different functions. 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. Rich