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

Mention elemidx and dataidx in the Linking.md documentation #193

Open
matovitch opened this issue Dec 3, 2022 · 3 comments
Open

Mention elemidx and dataidx in the Linking.md documentation #193

matovitch opened this issue Dec 3, 2022 · 3 comments

Comments

@matovitch
Copy link
Contributor

Hello,

I am writing a wasm backend for my compiler and I was planning to output relocatable wasm modules.

In the Linking.md document, there is no mention of dataidx and elemidx renumbering such that we would need to pad the LEB128 encodings of these to 5 bytes. I believe this should be new relocation types but these do not currently exist because LLVM does not support the element section or generate any memory.init or data.drop instruction.

I lost quite a bit of time wondering why the documentation did not address this issue. So here are my questions:

First, did I understood the problem properly and there is no mention of data or element segments reordering because these are not generated/supported by LLVM/lld?
Second, if this is correct, can I submit a PR updating the markdown documentation?

Thank you for your help. :)

@sbc100
Copy link
Member

sbc100 commented Dec 3, 2022

Yes, llvm doesn't have any support for generating first class data or element segments, so there are no relocation types for these, and no support in the linker.

If you would like to support such things a good place to start would be looking at adding support to lld (wasm-ld), and most likely the llvm assembly format (.s format).

BTW, is the existing support for data symbols not sufficient for your language? Do you really need first class data segments and element segments? I'd like to understand your use case here.

@matovitch
Copy link
Contributor Author

matovitch commented Dec 3, 2022

No it is probably sufficient for my language (it is sufficient for C++ after all ^^). I implemented the complete basic spec to generate non relocatable modules and was wondering how to adapt my code for instructions like data.drop, elem.drop, memory.init, table.init...etc. I can just avoid generating these instructions in the first place. But a mention in the documentation explaining why these types do not exist would have saved me a bit of time wondering why these were missing.

@sbc100
Copy link
Member

sbc100 commented Dec 3, 2022

Yes, there is currently no support for data.drop, elem.drop, memory.init, table.init, etc in the linkable format. We should add a "limitations" section I guess.

matovitch added a commit to matovitch/tool-conventions that referenced this issue Dec 3, 2022
matovitch added a commit to matovitch/tool-conventions that referenced this issue Dec 3, 2022
matovitch added a commit to matovitch/tool-conventions that referenced this issue Dec 3, 2022
matovitch added a commit to matovitch/tool-conventions that referenced this issue Dec 6, 2022
sbc100 pushed a commit that referenced this issue Dec 6, 2022
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