Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Browser support #24

Open
xermicus opened this issue Jul 4, 2024 · 9 comments
Open

Browser support #24

xermicus opened this issue Jul 4, 2024 · 9 comments
Assignees

Comments

@xermicus
Copy link
Member

xermicus commented Jul 4, 2024

We want easy integration for browser-based contract IDEs. Which in turn requires the compiler to be able to run in web browsers.

@xermicus
Copy link
Member Author

Note that the resolc binary (the solidity frontend) uses stdlib features heavily (threads via rayon, creates processes, calls itself recursively, reads from STDIN, writes files, etc.). I'd expect at least some of those things to work out of the box but I lack experience with the emscripten target.

The compilation process roughly looks like this (in a very simple case):

|
| -> resolc
  |-> solc
  |-> resolc
    |-> ld.lld
    |-> polkavm linker

The resolc binary depends on LLVM and solc. solc already runs fine in the browser. The polkavm linker is used as rust dependency directly so this should just work (altough might require changes how it is invoked).

Rough order of tasks (that can be more or less worked on independently):

  • Research on how to best compile a Rust project with LLVM dependencies inside the browser (best bet might be the emscripten target) and how we can bundle everything together
  • Extend the LLVM build script accordingly
  • A good starting point might be the linker, as it is an isolated and simple crate
  • inkwell is our LLVM wrapper crate and used for everything except the linker. I reckon that once this crate is compatible with our desired web target we should be good. Please upstream all changes to inkwell or llvm-sys should there be any required.
  • Implement the required changes in the solidity frontend

@ghost
Copy link

ghost commented Jul 19, 2024

There is a webassembly SDK at https://github.com/WebAssembly/wasi-sdk. This has a compiler that targets wasm and an implementation of libc in wasm. The compiler is LLVM-19 which is reported to support webassembly as a target.

There is also an effort from the YoWASP project to build LLVM to run in a wasm runtime. There is a discussion on the LLVM forum and PR. They have repositories for the patched LLVM and a build script and tools.

@smiasojed
Copy link
Collaborator

smiasojed commented Jul 25, 2024

@xermicus
Copy link
Member Author

xermicus commented Aug 8, 2024

Note that dependency resolution (parallel compilation) is done in separate processes. AFAIC LLVM uses globals. If creating multiple instances in different "processes" doesn't just work like that in the browser, the LLVM objects need to be mutexed.

@smiasojed
Copy link
Collaborator

emscripten does not allow to call Module.callMain from Module.callMain as it is implemented in revive so it is an issue

@xermicus
Copy link
Member Author

xermicus commented Aug 8, 2024

I think it might be easier to split the compilation process up and process the YUL files one by one using revives YUL mode (i.e. solc --ir + revive --yul)?

@smiasojed
Copy link
Collaborator

Does it change anything?
revive -> soljson-> yul works
yul -> RiscV has the issue that binary is calling itself in compile function

@xermicus
Copy link
Member Author

xermicus commented Aug 8, 2024

Ah yes of course you are right, the recursive call happens regardless of the pipeline.

However the code compiles fine regardless for emscripten? What does actually happen on process creation, how is this supposed to work?

@smiasojed
Copy link
Collaborator

Revive is compiled as an ES6 module. I think that for recursive execution, we need to instantiate an isolated module. Maybe Web Workers could be used. Simply reloading the module for a recursive call does not work.

@xermicus xermicus added this to the Initial release milestone Aug 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants