[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <HE1PR0502MB3883753444B685A97C1F29D5E70B0@HE1PR0502MB3883.eurprd05.prod.outlook.com>
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.
