stage2: Upstream zwld (partly) into wasm backend#10229
Merged
Merged
Conversation
Member
|
Nice work! The CI failure is due to compile errors from trying to build the compiler on 32-bit systems. You should be able to reproduce (even in zwld) by throwing a |
- Converts previous `DeclBlock` into `Atom`'s to also make them compatible when the rest of zlwd gets upstreamed and we can link with other object files. - Resolves function signatures and removes any duplicates, saving us a lot of potential bytes for larger projects. - We now create symbols for each decl of the respective type - We can now (but not implemented yet) perform proper relocations. - Having symbols and segment_info allows us to create an object file for wasm.
We now resolve relocations for globals, memory addresses and function indexes. Besides above, we now also emit imported functions correctly and create a corresponding undefined symbol for it, where as we create a defined symbol for all other cases. TODO: Make incrememental compilation work again with new linker infrastructure
This contains a few additions: - Proper stack pointer calculation keeping alignment in mind. - Setting up memory layout (including user flags). - Export or import memory - Handle 'easy' linker tasks during incremental compilation, while offloading heavy-tracking/computation tasks to `flush()` - This architecture allows us to easily integrate with the rest of 'zwld' to implement linking stage2 code with external object files.
7963598 to
6e88df4
Compare
Contributor
Author
Thanks for the pointer on the target, saved me a lot of time :). Fixed it in 6e88df4 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This upstreams a lot of logic from https://github.com/Luukdegram/zwld.
For now, I have chosen a hybrid method of linking, where easy-to-track and small computations are done using incremental style but hard-to-track linking is delayed until
flushModule(). This has the benefits of having more information available during the linking process, and not having to worry too much about updating all indexes constantly. Besides, this will allow us to merge the remaining parts of zwld (once it gains the missing features), with almost no effort, meaning we will then be able to link both stage1 as well as stage2 code with external object files.Prior to this PR, we were using a userland implementation of an offset table where we placed it inside wasm's memory. After this PR, we will generate and resolve relocations properly. We now have all the information available to also produce object files from the wasm backend, rather than only executables (once the emitting parts are implemented).
cc @kubkon