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

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

Hi Rich,

I've only just noticed your replies - sorry! (Some went in my spam, oops, maybe because of "dalias@aerifal.cx on behalf of dalias@libc.org".)

Thanks for the feedback, on this and the other patches.

On Thu, Dec 07, 2017 at 12:03:56PM -0500, Rich Felker wrote:
> __libc_start_init is intentionally not a public interface but part of
> musl internals. There is no reason to assume it will continue to exist
> with the same name or interface in future versions of musl. The public
> interface for the entry point is __libc_start_main.

That's right - it's a Musl internal. What I was planning to do though was to call it from within Musl, in the arch/wasm code. When I said it's a "public" symbol I meant "non-static/non-local" ie a symbol exposed for use within Musl.

> exit() is literally 9 instructions on x86_64, and likely comparably
> small elsewhere. I don't see how trying to optimize it out makes
> sense. The bulk of the code that runs at exit() when there's
> nontrivial work to do at exit time is linked through dependencies from
> other sources like stdio and atexit, and would be linked even if you
> succeeded in optimizing exit out.

To clarify, it's not exit() itself that's a problem. Remember we're using statically-linked syscalls, so linking in exit() introduces a dependency on SYS_exit_group/SYS_exit, which Wasm pulls in as external dependencies in the host emulation environment. It would be nice to avoid linking in syscalls that aren't actually used, especially ones like SYS_exit that are a bit ugly to emulate.

On Fri, Dec 15, 2017 at 04:19, Rich Felker wrote:
> Another bug I overlooked here was that, by moving the code to a new
> file, it would no longer be affected by $(NOSSP_SRCS) in Makefile,
> thereby breaking builds with -fstack-protector or where the compiler
> has it on by default. That could have been fixed if needed; I just
> bring it up to show that there are subtle possibilities for breakage
> like this that we should really either document rig up some sort of
> static assertion to catch if there's a regression.

Good point, I noticed that as well when splitting the file; I should have mentioned it. I misunderstood how the stack-protection stuff worked, and I looked at __init_libc and __libc_start_init and thought "these functions have normal/valid stack usage, no need to turn off the protection for these". But now I realise that it has to be turned off for all functions before __init_ssp.

Nick