[Enhacement] Allow hooking function calls and replacing Libraries by their Native Versions

[Fancy2209]

For example, sometimes you may need to stub a function from a dynamic library, you may also want to use the native version of libraries OpenGL or SDL2 for WASM instead of getting the lifted version for Linux working.

[yomaytk]

Thank you for the interesting suggestion.

At the moment, I think support for shared objects is the highest priority for elfconv.

For libraries that have already been ported to WebAssembly, it is usually easier and more efficient to use those native Wasm versions directly. So, as you mentioned, I agree that it would be valuable if Wasm applications generated by elfconv could link with existing Wasm libraries.

The reverse direction is also interesting. If Linux shared libraries distributed via package managers such as apt could be converted to Wasm, they could potentially be reused in WebAssembly applications developed with Emscripten (from C/C++ source code), for example by using Emscripten’s dynamic linking.

One question: do you have any specific use cases in mind where elfconv would be combined with libraries such as OpenGL or SDL2? I would be very interested to hear more about your ideas, if possible.

[Fancy2209]

I wanted to test a game from my Steam Library with a native x86 Linux port (would also help working on the x86 Lifting work, especially since it seems x86 32 bit hasn't been touched yet?) to test performance of elfconv on a performance critical app like a 3D video game, uses OpenAL, SDL1.2 (though SDL12-Compat exists to turn that into SDL2) and OpenGL

I was also thinking of some day using the lifter from elfconv lifter as a test seeing how feasible porting apps like videogames without the source code using all this tech would be (e.g. using the LLVM IR to target a console through homebrew, or a less supported OS like Haiku), after all from what I can tell the lifter doesn't have Web specific stuff, only the runtime.

Though mostly just because I like messing with graphical apps :)

[yomaytk]

Yes, x86 support is currently still limited. We plan to focus on improving support for x86-64 first, and 32-bit support will likely come later.

test performance of elfconv on a performance critical app like

If you encounter any cases where performance is not sufficient, please let us know by opening an issue.

I was also thinking of some day using the lifter from elfconv lifter as a test seeing how feasible porting apps like videogames without the source code using all this tech would be (e.g. using the LLVM IR to target a console through homebrew, or a less supported OS like Haiku), after all from what I can tell the lifter doesn't have Web specific stuff, only the runtime.

Though mostly just because I like messing with graphical apps :)

I see. When considering a new environment, ensuring system call compatibility is necessary, so additional implementation would be required. However, native environments such as macOS are closer to Linux compared to the browser, so depending on the application, the required work might not be too extensive. (For example, implementing fork/execve in the browser was non-trivial.)

Up to the LLVM IR translation stage, there is generally no platform-specific logic involved. With the latest remill build environment that we are currently discussing (#191), we expect that LLVM IR translation should also work on macOS and Windows.

[Fancy2209]

Yes, x86 support is currently still limited. We plan to focus on improving support for x86-64 first, and 32-bit support will likely come later.

test performance of elfconv on a performance critical app like

If you encounter any cases where performance is not sufficient, please let us know by opening an issue.

I was also thinking of some day using the lifter from elfconv lifter as a test seeing how feasible porting apps like videogames without the source code using all this tech would be (e.g. using the LLVM IR to target a console through homebrew, or a less supported OS like Haiku), after all from what I can tell the lifter doesn't have Web specific stuff, only the runtime.

Though mostly just because I like messing with graphical apps :)

I see. When considering a new environment, ensuring system call compatibility is necessary, so additional implementation would be required. However, native environments such as macOS are closer to Linux compared to the browser, so depending on the application, the required work might not be too extensive. (For example, implementing fork/execve in the browser was non-trivial.)

Up to the LLVM IR translation stage, there is generally no platform-specific logic involved. With the latest remill build environment that we are currently discussing (#191), we expect that LLVM IR translation should also work on macOS and Windows.

Why 64 bit first?
I thought x86_64 was an extension of x86, doesn't implementing one mean implementing the other?

[yomaytk]

You’re right that x86-64 shares a large portion of the x86 instruction set, so a lot of the implementation should be reusable. That said, I don’t think it’s simple enough to extend directly without extra work (for example, the register file is different).

We’d like to prioritize x86-64 since 64-bit environments are now the mainstream, and there is already an existing project that ports x86 binaries to the browser (https://github.com/leaningtech/cheerpx-meta), although it is not fully open source.

That said, considering that there is real demand for x86 support, as in your case, it would be great if we could implement support for both in parallel as much as possible.

[yomaytk]

Also, when I start focusing more seriously on x86 instruction support, any help with discussions or implementation would be very welcome.🙌