This patch adds a way for users to create their own custom sections to be added to wasm files. At the LLVM IR layer, they are defined through the "wasm.custom_sections" named metadata. The expected use case for this is bindings generators such as wasm-bindgen.
Diff Detail
- Repository
- rL LLVM
Event Timeline
Sorry maybe I'm jumping the gun here because haven't assigned a reviewer yet..
Can we have test in test/MC/WebAssembly too?
lib/MC/WasmObjectWriter.cpp | ||
---|---|---|
995 | would ArrayRef<char> ? Or ArrayRef<uint8_t> work better here? |
You're good. For LLVM patches, I'm accustomed to posting the patch first, and letting reviewers choose themselves, or in any case figuring it out later.
Can we have test in test/MC/WebAssembly too?
Added.
lib/MC/WasmObjectWriter.cpp | ||
---|---|---|
995 | I initially did exactly that, with ArrayRef and uint8_t, however writeBytes takes a SmallVectorImpl<char>. |
lib/MC/WasmObjectWriter.cpp | ||
---|---|---|
995 | It could be a bit less ugly with a typedef/"using=" for the std::pair (and in fact for all these vectors here which have rather long types) |
lib/MC/WasmObjectWriter.cpp | ||
---|---|---|
995 | Why does writeBytes not take an ArrayRef? There is an overload that takes a StringRef.. |
I think it's because writeBytes is defined to be passed data from an MCFragment's getContents(), which is a SmallVectorImpl<char>. That's the case here too, though the code that does the getContents() is a little separated from the writeBytes. Following @ncw's suggestion, I created a struct type, which not only avoids repeating the type name, but also makes the use of it cleaner than std::pair.
lib/MC/WasmObjectWriter.cpp | ||
---|---|---|
234 | This seems like it makes the code more complex than it needs to be. If you must change it from char* how about just StringRef Name = "" and use Name.empty() to check for its presence? Is ths part of the change needed for the new feature? | |
1077 | Use ArrayRef<char>, here and in WasmCustomSection? |
How do you expect the linker to handle these custom sections? We currently discard them. Will there be semantics for how to merge them, if there are name clashes, etc...?
I can't see a problem with the code and approach - don't wait on my review - but I'm just a bit hazy on the end-to-end story for bindings generators (which presumably will have to hook into things at the C level via a new attribute?)
I imagine that sections with the same name should be concatenated (with relocations as needed). At least this is what I think the linker currently does for debug sections in ELF. I could be wrong though.
This should probably be coordinated with https://reviews.llvm.org/D44184 since they both add custom sections. Maybe this should land first and the dwarf change can be simplified?
@sunfish do you have some time to look at this again and get it landed? I would like to start work on the lld-side, so the we can also get debug info working. (I can start before this lands of course, so just FYI really.)
I rebased and cleaned this up a litte: https://reviews.llvm.org/D45297. OK if I land?
This seems like it makes the code more complex than it needs to be.
If you must change it from char* how about just StringRef Name = "" and use Name.empty() to check for its presence?
Is ths part of the change needed for the new feature?