cfallin opened issue #7037:
This issue is meant to track what remains to make
wmemcheck
feature-complete and robust enough for practical use:
- [ ] Handle SIMD loads and stores (#6829)
- [ ] Hook
calloc
as well as existingmalloc
andfree
- [ ] Provide hooks for custom allocators to use
- [ ] Allow for more flexibility in heap and stack layout (don't assume stack is above
.data
/.bss
and everything below initial TOS is accessible)- [ ] Provide an alternate way to hook
malloc
/free
, rather than requiring a name section in the.wasm
module- [ ] Provide an option to print warnings as violations occur, rather than halting execution (like Valgrind)
- [ ] Provide a mechanism to define "suppressions" for unwanted warnings (like Valgrind)
- [ ] Track definedness at byte or bit level?
cc @iximeow for more thoughts, and others from today's Wasmtime meeting?
iximeow commented on issue #7037:
@alexcrichton noted earlier that it would be good to have:
- [ ] an end-to-end test starting with some clearly-UB .c and test expectations for a stack trace pointing to wasmtime trapping a bad access
and since wmemcheck doesn't support multiple memories (though we ought to make it so!),
- [ ] warn if a user tries to wmemcheck a multi-memory program
or add that support multiple memories. but i think that's maybe a step after "robust enough for practical use" in terms of effort, warning seems more expedient for now :)
iximeow edited a comment on issue #7037:
@alexcrichton noted earlier that it would be good to have:
- [ ] an end-to-end test starting with some clearly-UB .c and test expectations for a stack trace pointing to wasmtime trapping a bad access
and since wmemcheck doesn't support multiple memories (though we ought to make it so!),
- [ ] warn if a user tries to wmemcheck a multi-memory program
or add that support multiple memories. but i think that's maybe a step after "robust enough for practical use" in terms of effort, warning seems more expedient for now :)
Last updated: Dec 23 2024 at 13:07 UTC