emscripten-core / emscripten-core/emscripten
Overriding libc FS-related calls in Emscripten (for custom user's FS goodness)
- Dominant language
- C++
- Stars
- 27.6k
- Forks
- 3.6k
- Avg merge
- 1d 1h
- Merged PRs (30d)
- 105
Description
I've implemented a read-only, virtual FS - for supporting "data package-like" ZIP-archives with musl libc by copying libc.a (for further linkage), prefixing FS-related symbols with `orig_` using `objcopy` (e.g. `open -> `orig_open`) and then I'm defining `open(...)` (and other related FS functions) in my own code (which calls `orig_open` under the hood when the accessed path does not match the virtual FS one).
Is it feasible to reuse my custom `open(...)` code with Emscripten/libc somehow?
For now, LLVM does not have support for renaming WASM symbols:
- https://github.com/llvm/llvm-project/issues/50623
Does Emscripten support using `dlsym(RTLD_NEXT, "open");` specifically for libc?
Or maybe is there another way to share my implementation code between regular musl libc and Emscripten/libc (and hook/override the Emscripten/libc default FS-related functions)?
(in this way I can come up with my own portable impl of "data packages", so that the data packages can be used with both Emscripten and not Emscripten, and so that multiple compression formats of data packages can be supported and experimenting with no ahead-of-time decompression)
Thanks!
---
Basically looking for a portable (so should work outside Emscripten context as well), minimalistic (hopefully header-only), non-intrusive libc-level virtual FS support - my take was overriding some FS posix/libc/c functions sufficient for my application, a more complete virtual FS support is a more complex (and still leaky) feat... Some related attempts:
- https://github.com/dphilla/wasm-vfs
- https://github.com/sholtrop/ldpfuse/blob/master/ldp_fuse/include/ldpfuse.h
- built-in "/zipos/" support in https://github.com/jart/cosmopolitan/ libc variant
- https://github.com/emscripten-core/emscripten/discussions/20764
Contributor guide
Assessment
This issue has not been assessed yet.