std.debug.StackIterator in embedded throws compile error for ucontext_t being missing in std.posix.system
Zig Version
0.14.0-dev.468+aa73bb6bc
Steps to Reproduce and Observed Behavior
- Write a kernel (or something else embedded)
- Implement a custom panic handler which uses std.debug.StackIterator
- Get a compile error (
std/posix.zig:153:30: error: struct 'posix.system__struct_2080' has no member named 'ucontext_t')
Expected Behavior
I expected this compilation to work, as it did some days ago.
As far as I know, this behavior regressed in e8c4e79.
Reproduced by compiling:
const std = @import("std");
export fn _start() void {
var it = std.debug.StackIterator.init(null, null);
while (it.next()) |addr| {
std.mem.doNotOptimizeAway(addr);
}
}
with zig build-exe -target native-freestanding main.zig.
The debug.zig module imports std.posix, but tries to detect which bits of posix are present or not. The compile is failing on the line meant to do the detection:
pub const have_ucontext = posix.ucontext_t != void;
In std.posix ucontext_t is defined via pub const ucontext_t = system.ucontext_t;, and system is from:
pub const system = if (use_libc)
std.c
else switch (native_os) {
.linux => linux,
.plan9 => std.os.plan9,
else => struct {},
};
The empty struct there has no ucontext_t. So this problem would impact any compile without a libc, for platforms other than Linux and Plan9, I think?
One fix is to add a void ucontext_t into the default system object:
@@ -45,7 +45,9 @@ pub const system = if (use_libc)
else switch (native_os) {
.linux => linux,
.plan9 => std.os.plan9,
- else => struct {},
+ else => struct {
+ pub const ucontext_t = void;
+ },
};
pub const AF = system.AF;
But it seems awkward for the default system to declare all the things it doesn't support? (Presumably there is a long list of other identifiers to void out like this.)
Alternatively, the std.debug code could switch back to using @hasDecl for feature detection. Or, the std.debug code could reduce its Posix dependency or move the Posix-dependent parts out to somewhere else?
Also, seems like there should be tests against freestanding targets for the parts of debug that should work with them.
I'll assume the patch I suggested above is the best idea for now (and will put a PR together for that), but if anyone with more of a clue has other ideas let me know.