Description
Zig Version
0.14.0-dev.3259+0779e847f
Steps to Reproduce and Observed Behavior
Hey there, I noticed some odd behavior from the self-hosted backend today when trying to get uscope to debug binaries generated by the self-hosted backend. I am unsure that any debugger would parse this properly as I think it's in violation of the DWARF v5 spec, which Zig is using in this case.
This program:
const std = @import("std");
pub fn main() !void {
std.debug.print("Hello, world!\n", .{});
}Built with:
zigup run 0.14.0-dev.3259+0779e847f build-exe -fno-llvm -fno-lld main.zig
Produces a valid executable that prints Hello, world! when it runs, but the DWARF debug info is invalid. dwarfdump chokes with this error message.
readelf --debug-dump=info main produces this, with some warnings as noted below. As you can see, about half-way down the first compile unit, there's a ton of null entries, which I think is going to cause most debuggers to bail out (in my case, I caught this because I have an assert that enforces that I've scanned the full compile unit in the .debug_info section).
$ readelf --debug-dump=info main | wc -l
readelf: Warning: Bogus end-of-siblings marker detected at offset 329 in .debug_info section
readelf: Warning: Bogus end-of-siblings marker detected at offset 32a in .debug_info section
readelf: Warning: Bogus end-of-siblings marker detected at offset 32b in .debug_info section
readelf: Warning: Further warnings about bogus end-of-sibling markers suppressed
163158
Are these repeated entries just padding? If yes, why is it there? I've never seen another compiler do this.
Expected Behavior
Each compile unit ends with a single null entry to signal that we've reached the end of its DIEs, and the length of its section exactly matches what is specified in the compile unit header.
Activity