Static ctors in wasm

H. S. Teoh hsteoh at qfbox.info
Fri Feb 9 18:39:23 UTC 2024


On Fri, Feb 09, 2024 at 01:17:26AM +0000, kinke via Digitalmars-d wrote:
> On Friday, 9 February 2024 at 00:48:47 UTC, kinke wrote:
> > So if wasm doesn't support named sections/data ranges
> 
> Oh well, looks like wasm-ld (i.e., lld) supports exactly the same magic
> `__{start,stop}_*` symbols as for ELF:
> https://github.com/llvm/llvm-project/issues/55839

Oh cool!

But is ModuleInfo emitted when compiling with --fno-rtti? I adapted
Sebastiaan Koppe's code to traverse module info at runtime, but I'm
getting an empty list... or maybe I missed something, as usual.


On Fri, Feb 09, 2024 at 07:21:04AM +0000, Sebastiaan Koppe via Digitalmars-d wrote:
[...]
> Might I direct you to my past efforts of a druntime port? This is a
> good entry point https://github.com/skoppe/ldc/tree/wasm as it
> contains the changes for LDC and submodules for Phobos and druntime.

Thanks, that was very helpful!


> I got everything working, except for things that aren't supported like
> exceptions and fibers.

Hmm.  I wonder if it's possible to implement exceptions without stack
unwinding. Like using sumtypes or a dedicated error flag/register under
the hood, with the compiler transparently inserting the necessary
branches after calling a non-nothrow function.  Would require a major
ABI change though, may not be feasible.  But this could be a good
opportunity to experiment with alternative exception implementations.


[...]
> The other issue is the GC not seeing all pointers hence freeing too
> much. As mentioned in another thread this can be solved by spilling
> the pointers to the shadow stack, which involves either changes to
> LDC/llvm or doing a post build step. Nowadays there is binaryen which
> reimplemented the required pass. I haven't been able to test it but
> others have used it with a similar Böhm GC.

I'll look into it when I get to that point. :-D  Currently, for my
purposes, it's Good Enough(tm) to preallocate everything in a setup
function and then just use a bump-the-pointer allocator per callback,
resetting to last pointer location afterwards. Sorta like a poor man's
region allocator. As long as no pointers persist beyond the callback I
should be OK.


T

-- 
Ph.D. = Permanent head Damage


More information about the Digitalmars-d mailing list