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

[Rich Felker <dalias@libc.org>]

On Sat, Dec 16, 2017 at 01:21:39PM +0000, Nicholas Wilson wrote:
> On 15 December 2017 17:56, Rich Felker wrote:
> > 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.
> 
> Thanks for clarifying, I understand now. In our fork/branch, we will
> have to call *something* on Wasm, since initialisation is different
> to ELF and the default crt1.c doesn't really work for non-ELF archs.
> 
> For your information, what we'll do is call __init_libc directly
> from crt/wasm/crt1.c, since for the time being we need to do that to
> keep the prototype working. It would be nice if that were to become
> an accepted internal Musl interface, so that becomes "legal".
> 
> (I have though reverted the split into two files of __libc_start_main.c.)

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". It does require a pointer to the args/environment
formatted as an array of:

	{ argc, argv[0], ..., argv[argc-1], 0, environ[0], ..., 0,
	auxv[0], ... 0 }

but __init_libc and other code in musl also requires such an array to
be present. I really don't think you're gaining anything by bypassing
__libc_start_main, but you are losing the property of interfacing with
a stable interface that will never change out from under you.

Rich