zig
zig copied to clipboard
ziglang
integer cast truncated bits in Dwarf.zig in kernel mode
Zig Version
0.14.0
Steps to Reproduce and Observed Behavior
When using eh_frame for stack traces in a kernel-mode binary, https://github.com/ziglang/zig/blob/0.14.0/lib/std/debug/Dwarf.zig#L2088 tries to cast a kernel-mode address (a usize with the top bit set) to an i64, which cannot represent the full data. This issue is unfortunately really hard to debug, as it affects debugging itself including the necessary stack traces, but running zig build qemu -Doptimize=ReleaseSafe on the agony branch of my imaginarium project after a recursive clone is enough to demonstrate.
Expected Behavior
No panic to be generated and the addition to proceed normally. I think using i65 instead of i64 may be sufficient in this case and will test but Im uncertain.
Update: changing the i64s to i65s on that line of Dwarf.zig did (at least seemingly for now) fix the issue for me.
EDIT: worth noting that changing to i65 is a semantic change and likely to break the overflow handling that function has. using i64 but bitCast-ing instead of intCast-ing might work, as generally single binaries dont exist in both higher-half and lower-half address spaces, but im not 100% sure and dont know the true best way to handle this
Looks like replacing the intCasts on that line with bitCasts works, at least in my local testing. Wish I knew more about how Dwarf works and is formatted to be able to say for sure if its semantically correct though.
It looks like #25227 changed this code and may have fixed this (the code in question moved to std/debug/Dwarf/Unwind.zig see here, and looks like the new code handles signed values a bit better.
looks like it might have but im having trouble mentally parsing the code, so waiting for confirmation from mlugg on this. I cant test myself as Im blocked on updating my project by #24522
Yep, the new logic should solve this problem. I'll close this issue, but if at any point it turns out there's still an issue, feel free to open another issue @Khitiara.
Incidentally, I find myself having to do this kind of thing for safe arithmetic a lot, and just want to note that #3806 would make this class of bug go from common (applying a signed offset to an unsigned value is a surprisingly common use case!) and difficult to solve, to rare and trivial to solve.
