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

[Nicholas Wilson <nicholas.wilson@realvnc.com>]

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 whether 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 Wasm users don't want that. We need to able to call into the Wasm module repeatedly 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 JavaScript environment to run repeatedly. We're not using the language of "shared library" though, because we're using that terminology to mean Wasm libraries 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://github.com/NWilson/musl/blob/musl-wasm-native/crt/wasm/crt1.c)

Another difference is that __libc_start_init uses the __init_array_start/end symbols, which come from special compiler-provided crtbegin.o/crtend.o objects on ELF platforms. The linker has to arrange for a table of function pointers 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, since that would mean taking the address of those functions, and they otherwise would be unlikely to need to go in the function pointer table. It's a hardening 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-instructions, 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 whether it would be unhelpful to diverge from ELF like this, but the consensus was 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 it'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 start 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 OK, that's an ELF convention that we're quite happy to follow to reduce friction with Musl. In general, where possible I don't have a problem with emulating ELF.

Thanks for your patience and for asking questions. I hope the answers help!

Nick