-
Notifications
You must be signed in to change notification settings - Fork 737
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
wasm-split confused about overlapping segments #6693
Comments
wasm-split assumes that the module (and in particular the table and element segments) don't look too different from a normal statically linked or shared library emitted by LLVM and wasm-ld. I'm not surprised that things go wrong when there are overlapping active segments. The best fix is probably to implement this TODO to use a fresh table that cannot possibly interfere with the original program when reference-types are enabled, then fuzz with reference-types unconditionally enabled. |
Do you think there might be many more such assumptions? This one sounds easy enough to handle, but if there is a lot then maybe this is not worth doing. The context for me here is to use wasm-split + wasm2js to fuzz the wasm/JS boundary, but that only makes sense if there isn't too much work to get both of those things fuzzable. |
No, table management should be the only problem area since we previously supported only one table and wasm-split needed to modify it. Memories are similarly a problem area without multi-memory, but only for multithreaded profiling, so I don't think that will be a problem for you. |
Ok, I tried to implement that TODO here: https://github.com/WebAssembly/binaryen/compare/main...kripken:binaryen:split.new.table?expand=1 But the results aren't right, and I think there is some underlying assumption or bug in code I am not familiar with. The new table that is created is of size 0, and if there is nothing to put there in the primary module then it stays at size 0, but if the secondary module needs to put something there then it tries to add to a size-0 table, which errors. That is, when the secondary module needs more space, the table initial size (declared in both modules) must be larger, but that isn't happening. I tried to look into this but I saw that |
I can take a deeper look at this. |
#6726 should fix this problem when reference-types are enabled. Is that enough to close this issue? |
(At least that is my guess as to what is going wrong here, I'm not sure.)
Testcase:
The testcase doesn't do much: one export, which is an empty function with no params or results. After splitting it crashes, though.
Split command:
Primary module:
This already looks odd. The exported function (now
$6
) does acall_indirect
at index 10. There are two elems that write that index, that overlap. One writes$fimport$2
and the other$fimport$5
. The last one wins. But$fimport$5
has a very different type than$0
so the VM errors.But there might be more going wrong here than overlapping segments. This is the secondary module:
It writes function
$4
to index 10, but it has the weird signature again, so that is also wrong.@tlively is this a known issue?
The text was updated successfully, but these errors were encountered: