Add basic tests for grates.

[stupendoussuperpowers]

This PR adds some basic regression tests for common grate patterns/endpoints.

• register-basic.c: Check the register_handler function for registration.
• register-deregister.c: Test for de-registration and re-registration for a syscall num.
• register-duplicate.c: Test duplicate registrations for a syscall num.
• register-multi-syscall.c: Test registering 2 different syscall nums.
• copy-data-basic.c: Test copy-in and copy-out for copy_data_between_cages

The scripts/wasmtestreport.py has also been modified to include the tests/grate-tests folder in the test runs.

[stupendoussuperpowers]

For reviewers:

The changes to the test script were to ensure that the grate specific compile script is used.

Since these tests can only run on lind, they are treated like non-deterministic tests where we use asserts to mark a passing/failing test.

I am not sure if grate-tests belong on the top level like they currently do, or within unit-tests/grate_tests/..., I feel like the current structure makes more sense.

[JustinCappos]

Maybe add one instead? If the geteuid is 0, this grate doesn't change the value.

[JustinCappos]

@Yaxuan-w @stupendoussuperpowers Why should this fail? Why doesn't it overwrite?

I'm not saying you are wrong. I just want to understand the logic

[stupendoussuperpowers]

lind-wasm/src/threei/src/threei.rs

Lines 324 to 327 in 148d55f

	/// If a conflicting mapping exists, the function panics to prevent accidental overwrite.
	///
	/// If a handler is already registered for this (syscall number, in grate function address) pair with the same
	/// destination cage, the call is treated as a no-op.

Based on the comments on the function, I believe this is to discourage accidental overwrites. Probably the behavior we're pushing for is to deregister, and then reregister in case we want the mapping to be updated.

[JustinCappos]

I'd change the *2 to be something else like +1 which will always change the value. Overall, these seem reasonable (but another reviewer needs to run them before merging).

[JustinCappos]

Isn't it usually the case you're overwriting an existing handler? Is this always the case unless you have a system call that isn't currently mapped to any function? Also, from the link you posted I noticed: /// If a handler is already registered for this (syscall number, in grate function address) pair with the same /// destination cage, the call is treated as a no-op. Does this mean if the same handler was already registered or if any handler is? It sounds like the latter, which is odd and will lead to accidental errors.

…

On Fri, Jan 2, 2026 at 11:38 AM Sanchit Sahay ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In tests/grate-tests/register-duplicate.c <#590 (comment)> : > + geteuid_orig = geteuid(); + + ASSERT(geteuid(), geteuid_orig); + + uint64_t fn_ptr_addr = (uint64_t)(uintptr_t)&geteuid_grate; + int ret = register_handler(grateid, 107, 1, grateid, fn_ptr_addr); + + ASSERT(ret, 0); + ASSERT(geteuid(), 2 * geteuid_orig); + + // Duplicate registration is a no-op + ret = register_handler(grateid, 107, 1, grateid, fn_ptr_addr); + ASSERT(ret, 0); + + // Conflicting register should fail + ret = register_handler(grateid, 107, 1, grateid + 1, fn_ptr_addr); https://github.com/Lind-Project/lind-wasm/blob/148d55f7eddf0ec07db65b014913e8b856e5194c/src/threei/src/threei.rs#L324-L327 Based on the comments on the function, I believe this is to discourage accidental overwrites. Probably the behavior we're pushing for is to deregister, and then reregister in case we want the mapping to be updated. — Reply to this email directly, view it on GitHub <#590 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGROD5GDBN6ZLGVBGZRHXD4E2NIXAVCNFSM6AAAAACQQVQMPCVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTMMRTGQ4TOMZTGM> . You are receiving this because you commented.Message ID: ***@***.***>

[stupendoussuperpowers]

It's only a no-op if the handler is also the same.

[JustinCappos]

So you have one function which can only "unset" it and the other can only "set" it. Would it make sense for register_handler to instead take a flag to indicate whether it expects it to be empty or not? I'm not sure whether this matters or not. I'm just trying to think through what is clearer for a reader. Perhaps have this in mind as you write a few grates and we can tweak the API as is needed.

…

On Fri, Jan 2, 2026 at 10:37 PM Sanchit Sahay ***@***.***> wrote: *stupendoussuperpowers* left a comment (Lind-Project/lind-wasm#590) <#590 (comment)> It's only a no-op if the handler is also the same. — Reply to this email directly, view it on GitHub <#590 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGROD27WIXJXFUH3ZLVM2D4E42QLAVCNFSM6AAAAACQQVQMPCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOMBWGY2TSMJQGA> . You are receiving this because you commented.Message ID: ***@***.***>

[stupendoussuperpowers]

Will keep this in mind. Currently it's 0 -> deregister, non-0 -> register. We could multiplex on this parameter to add that feature if needed.

Unrelated to this, I think the lind_syscall.h should also include the constants we use for threei. For example, in this test I had to manually define the ELINDAPIABORTED constant in the test case file.

Similarly, the lind_syscall_num.h is not a part of sysroot includes, but it should be. This is so that we use GETEUID_NUM instead of having to look up the number 107 when writing grates.

[Yaxuan-w]

I'm bit confused on these tests flows... It seems only grate files for each...?

[Yaxuan-w]

Using same test file for only register_handler related tests makes sense to me. However, I'm a bit worried about other 3i syscall routine related tests. It's a bit different from how grates are suppose to be used in general cases.

Also would be helpful to have comments about each tests

[Yaxuan-w]

I'd suggest that to keep geteuid related tests and we can have a separate PR for test script.