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

[Rich Felker <dalias@libc.org>]

On Thu, Dec 07, 2017 at 12:03:56PM -0500, Rich Felker wrote:
> On Thu, Dec 07, 2017 at 02:51:31PM +0000, Nicholas Wilson wrote:
> > Hi,
> > 
> > I've got some more patches to try and get in for Wasm support.
> > 
> > Here's one that should be fairly straightforward? In Musl, most
> > (non-static) functions are in a file of their own, which is good
> > from a linkage point of view.
> > 
> > I'd like to have __libc_start_main.c split into two files, because
> > for Wasm I'd like to be able to call __libc_start_init (from within
> > the CRT directory) but without having to link in exit(), since many
> > Wasm applications will never call exit() and won't necessarily use
> > main.
> > 
> > There's no pollution of the codebase, it's purely splitting a file.
> > 
> > Patch below.
> 
> __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.
> 
> 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.

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.

Rich