ziglang
debug.zig: Make it build with 'other' target OS
Make std.debug.StackIterator compile on the other OS target, and port the "unwind_freestanding" test case to the other OS target.
Inspired by #20833 which reported the original problem and pin-pointed the issue.
[Edited summary and PR a couple times.]
Looks like Wasi has an msync symbol visible, but depending on it in std.debug creates unwanted libc dependencies (?), so I have to prevent an msync dependency in std.debug when building against Wasi targets.
I am pushing this change in the direction you suggested. It will take me a bit of time (all I know of WASI is what I'm learning in the Zig source tree...). I believe the three existing commits in this PR are mostly independent of the WASI cleanup (other than forcing the issue to be a bit more apparent), so I don't think you need to hold up review/submit of those. But unless I hear otherwise, I'll assume you want the WASI fixes on this PR and will push a new version here once I get through the fallout ...
@andrewrk would you prefer the posix.mode_t resolve to void or u0 for Wasi-without-libc targets?
The "void" seems more correct to me, but the existing Windows targets in Zig implicitly map posix.system.mode_t to u0 (AFAICT, its the same underlying motivation -- POSIX file modes are not supported by the Windows target). Having both void for Wasi and u0 for Windows can work (its what I have currently in my tree), but it is a bit clumsy.
I recommend setting posix.system.mode_t to void for Wasi-without-libc, and also fixing the Windows implementation to match. But I wasn't sure if there was some reason the u0 might be preferred, or if the Windows case is different.
I recommend setting
posix.system.mode_ttovoidfor Wasi-without-libc, and also fixing the Windows implementation to match. But I wasn't sure if there was some reason theu0might be preferred, or if the Windows case is different.
I think it's a good recommendation; let's do that.
I've forked the more general WASI POSIX cleanup changes to #20991, as they got large. I know a bit more about WASM now, so I've cleaned up this PR to make the msync symbol {} on WASI (so the MemoryAccessor.zig code can just check for msync-or-not without getting caught up in the platform details). I think this is ready for review and fixes the issue reported in #20833.
I updated this PR for the recent panic changes. I simplified this PR a lot too. Now it just does the minimal necessary to get the "other" target OS to work as well as the "freestanding" target does for std.debug.StackIterator. No more mucking about with tangential improvements to msync detection. Please give this a fresh look.