Re: [PATCH] split __libc_start_main.c into two files (Wasm)

[Rich Felker <dalias@libc.org>]

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