www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - LDC wasm target: suppressing needless exports?

reply "H. S. Teoh" <hsteoh qfbox.info> writes:
Lately I've been playing around with targeting wasm using LDC's wasm
target.  (So far got enough of it working that I can write betterC-level
D code and have it work in the browser -- certainly a welcome change
from having to deal with Javascript's oddities and limitations. Plans
are on the way to getting a rudimentary minimal druntime running so that
I can start writing "real" D. :-P)

One thing I noticed, though, is that LDC seems to export all functions
(including private ones!) to the generated .wasm file's export section.
Meaning that they can be accessed from the JS side, etc..  Most of this
is actually unnecessary, though, since I only have about 2-3 functions
that actually need to be called from JS; everything else is internal D
code.  Is there a way to suppress this auto-exporting and only do it for
a few select functions?

It's mostly harmless, except that when I start using template functions
the size of the symbols explode and needlessly bloats up my .wasm
executable. Would be nice to trim off this fat.


T

-- 
Ignorance is bliss... until you suffer the consequences!
Feb 01
next sibling parent Sergey <kornburn yandex.ru> writes:
On Thursday, 1 February 2024 at 18:41:10 UTC, H. S. Teoh wrote:


 Plans are on the way to getting a rudimentary minimal druntime 
 running so that I can start writing "real" D. :-P)


Just in case you didn't see those links before:

DRuntime work:
https://forum.dlang.org/thread/zsmhhoruiyzplskgjtgr forum.dlang.org

And some other works related to betterC mode:
https://github.com/etcimon/libwasm

Article: Getting started with D on WebAssembly: 
https://brianush1.github.io/wasm-setup.html (glue code: 
https://github.com/brianush1/d-wasm-glue)
Feb 01
prev sibling next sibling parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Thursday, 1 February 2024 at 18:41:10 UTC, H. S. Teoh wrote:

 Lately I've been playing around with targeting wasm using LDC's 
 wasm target.  (So far got enough of it working that I can write 
 betterC-level D code and have it work in the browser -- 
 certainly a welcome change from having to deal with 
 Javascript's oddities and limitations. Plans are on the way to 
 getting a rudimentary minimal druntime running so that I can 
 start writing "real" D. :-P)

 One thing I noticed, though, is that LDC seems to export all 
 functions (including private ones!) to the generated .wasm 
 file's export section. Meaning that they can be accessed from 
 the JS side, etc..  Most of this is actually unnecessary, 
 though, since I only have about 2-3 functions that actually 
 need to be called from JS; everything else is internal D code.  
 Is there a way to suppress this auto-exporting and only do it 
 for a few select functions?

 It's mostly harmless, except that when I start using template 
 functions the size of the symbols explode and needlessly bloats 
 up my .wasm executable. Would be nice to trim off this fat.


 T


Try to compile with:

``--f-visibility=hidden``
Feb 01
parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
oops, it is: ``--fvisibility=hidden``
Feb 01
parent ryuukk_ <ryuukk.dev gmail.com> writes:
Also this to optimize/trim your wasm files:

``wasm-opt -Oz -o bin/game.wasm``

This tool comes with emscripten package
Feb 01
prev sibling parent "H. S. Teoh" <hsteoh qfbox.info> writes:
On Thu, Feb 01, 2024 at 07:19:55PM +0000, ryuukk_ via Digitalmars-d wrote:

 oops, it is: ``--fvisibility=hidden``


On Thu, Feb 01, 2024 at 07:21:31PM +0000, ryuukk_ via Digitalmars-d wrote:

 Also this to optimize/trim your wasm files:
 
 ``wasm-opt -Oz -o bin/game.wasm``


[...]

Cool, thanks!  That got rid of a lot of symbol bloat.

Now I've started putting together a minimal druntime so that I don't
have to compile with -betterC anymore.  Discovered that a good amount of
bloat comes from RTTI in the way of the TypeInfo_Xxx classes, which I
currently don't need.  Luckily, compiling with --fno-rtti allowed me to
eliminate TypeInfo from my minimal druntime (currently I have them
versioned out under version(RTTI), disabled by default) and keep the
bloat to a minimum.

Next step is to implement a dumb bump-the-pointer allocator so that
things like array concatenation would Just Work(tm). Well, provided you
don't do it inside a loop. I'm not planning to write a GC for wasm just
yet.

(Due to the possibility of passing references across the JS/wasm
boundary, and the fact that wasm code can't examine JS references or
even its own runtime stack, it may not actually be possible to implement
a sound GC at all. But now that V8 officially supports WasmGC, it's just
a matter of time before LLVM picks it up, then maybe I won't ever have
to implement a GC. :-P  It's kinda silly anyway since the wasm/JS host
already has a running GC; we just need a way of leveraging it from
inside the wasm sandbox. No sense bloating the wasm executable with a
full GC implementation when the host already has one!)

Anyway, all of this is making little steps toward the point where I
could just take a random D program and compile it for wasm, and with my
wasm JS shim and minimal druntime it should Just Work(tm).


T

-- 
Those who've learned LaTeX swear by it. Those who are learning LaTeX swear at
it. -- Pete Bleackley
Feb 02