search

WebAssembly / wabt

The WebAssembly Binary Toolkit
Apache License 2.0
6.91k stars 702 forks source link

wasm2c: update memory/table operations to use u64 + harmonize checks #2506

Open keithw opened 2 weeks ago

keithw commented 2 weeks ago

The PR updates the bulk memory operations (memory.fill, memory.copy, table.fill, etc.) to support 64-bit addresses and counts, and standardizes on a 64-bit version of RANGE_CHECK everywhere.

Previously we were only taking u32's for these arguments, even with memory64 enabled. (I don't think the memory64 tests check the ability to use memory.copy or the other operations beyond the first 4 GiB of a memory -- I wonder if there would be a way to add this as an "intensive" test if people don't mind having to allocate >4 GiB to run the test.)

This is a stepping-stone to being able to mix software-bounds-checked i64 memories and "guard-page-checked" i32 memories in the same module (#2507) and supporting custom-page-sizes (#2508).

shravanrn commented 2 weeks ago

I wonder if there would be a way to add this as an "intensive" test if people don't mind having to allocate >4 GiB to run the test.

Is the concern that the test-suite may not run on small machines?

One thought I had to run at least simple tests due to lazy memory allocation on Linux-like OSes? If tests are of the form such as below:

create wasm memory of 8 GB
memcpy 100 bytes at index 100
memcpy 100 bytes at index 4GB + 100

this should end up allocating only two physical pages for the heap. So apart from the large virtual memory footprint, the test should run fine even on small machines?

keithw commented 2 weeks ago

I wonder if there would be a way to add this as an "intensive" test if people don't mind having to allocate >4 GiB to run the test.

Is the concern that the test-suite may not run on small machines?

Yeah, and also that a test could be really slow to run (e.g. memory.fill with an "n" greater than UINT32_MAX).