Date: Fri, 15 Dec 2017 11:34:10 +0000 From: Nicholas Wilson <nicholas.wilson@...lvnc.com> To: "musl@...ts.openwall.com" <musl@...ts.openwall.com> Subject: Re: [PATCH] split __libc_start_main.c into two files (Wasm) Hi Rich, I've only just noticed your replies - sorry! (Some went in my spam, oops, maybe because of "dalias@...ifal.cx on behalf of dalias@...c.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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.