[browser][mono] Resolve LibraryImport via dlopen/dlsym for WASM side modules (#123570)#123634
[browser][mono] Resolve LibraryImport via dlopen/dlsym for WASM side modules (#123570)#123634denis-kudelin wants to merge 1 commit intodotnet:mainfrom
Conversation
|
@dotnet-policy-service agree |
4c1bf12 to
60b6939
Compare
|
Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara |
Originally posted by @pavelsavara in #123571 (comment) The demo is literally why I ended up going down this path.. I originally wanted a showcase of my very “tricky” algorithm, but since I’m planning to ship its core via NuGet I also want to make reversing harder… and it escalated, as usual...... Multi-threading and low latency are non-negotiable for me. First priority is getting the full setup running end-to-end, and only after that I’ll circle back to the remaining questions with concrete artifacts/answers and provide a deliberately deep benchmark demo, no problem. |
I guess if not… is a PR even worth it? I just don’t want to be stuck maintaining this…)) |
I don't know yet if it's worth merging it. I hope that we would learn this from your experiment. |
…t#123570) Signed-off-by: Denis Kudelin <15978569+denis-kudelin@users.noreply.github.com>
6861e8b to
aa85d49
Compare
Fixes #123570
Summary
Enable LibraryImport to resolve symbols from Emscripten side modules by falling back to dlopen/dlsym after the pinvoke table check, and surface meaningful managed errors on failure.
Motivation
In browser-wasm with MAIN_MODULE/SIDE_MODULE, LibraryImport names are not in the generated pinvoke table. Without a dlopen/dlsym fallback, side modules cannot be resolved even when present.
Changes