[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <VI1PR0502MB38855A047B7B355FD43037B3E73A0@VI1PR0502MB3885.eurprd05.prod.outlook.com>
Date: Tue, 28 Nov 2017 17:53:27 +0000
From: Nicholas Wilson <nicholas.wilson@...lvnc.com>
To: "musl@...ts.openwall.com" <musl@...ts.openwall.com>
Subject: Re: [PATCH] Wasm support patch 2 (static syscalls)
Thanks John! In fact we'd have to cast them through an int, since Musl sometimes stores syscall numbers in an int, but that cast is safe on Wasm since function pointers are just an index into a global array of functions, so are guaranteed to be "small".
It's cunning, and I like it!
OK, so this patch can also be scrapped, I think it's not necessary with John's idea.
Nick
________________________________________
From: John Starks <John.Starks@...rosoft.com>
Sent: 28 November 2017 16:51:19
To: musl@...ts.openwall.com
Subject: RE: [musl] [PATCH] Wasm support patch 2 (static syscalls)
What if you redefine the syscall numbers in wasm to be function pointers to the actual syscalls, e.g. #define SYS_unlink ((long)&__syscall_unlink). Then __syscall and friends can just apply the arguments to the function pointer. This should play nice with the linker and probably optimizes well.
-----Original Message-----
From: Nicholas Wilson [mailto:nicholas.wilson@...lvnc.com]
Sent: Tuesday, November 28, 2017 6:35 AM
To: musl@...ts.openwall.com
Subject: Re: [musl] [PATCH] Wasm support patch 2 (static syscalls)
That's some sophisticated link-time optimisation you're expecting there! DCE on a single source file wouldn't do it.
When you have callers like __setxid, it's not until the final link that that kind of elimination could be run; just by examining setxid.c there's no way the compiler could eliminate anything. And, it would rely on several stages of inlining taking place, which you really can't guarantee. (Not to mention that the Clang LLD linker doesn't do LTO.) The traditional unix linking model isn't really geared up for this level of link-time inlining and optimising.
The current Emscripten fork of Musl implements the "static syscalls" a little differently. They have retained the numeric constants for the syscalls, but the calls are redirected to functions with names like "__syscall_42" instead of "__syscall_getpid". At the end of the day, there isn't a big difference between my approach here and the current Emscripten one - I've just reduced the amount of Musl code that needs to be touched to support the static syscalls, and I can't see how to reduce the changes further...
Nick
________________________________________
From: Szabolcs Nagy <nsz@...t70.net>
Sent: 28 November 2017 14:05:31
To: musl@...ts.openwall.com
Subject: Re: [musl] [PATCH] Wasm support patch 2 (static syscalls)
* Nicholas Wilson <nicholas.wilson@...lvnc.com> [2017-11-28 13:23:15 +0000]:
> With a jump table like that, you can't get static linkage. The compiler will link in *every* syscall.
use a better compiler with dce then.
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.
