Support loadable debuginfo on freestanding

[sm2n]

Context

I'm working on a program that runs on freestanding. It should be able to debug/introspect itself, like in this blog post. Specifically, for now I'd like to have full stack traces. Currently, this appears to be impossible to implement.

Issue

The blocker is that to get good stack traces, access to dwarf debuginfo is needed at runtime. Normally, this would happen by introspecting the elf file the program was loaded from, but this is not available on freestanding.

On freestanding, we need to get the debuginfo into memory that is loaded at runtime, so that we can call the functions from std.debug/std.dwarf on it. However, by default debuginfo is not loaded because they are not marked ALLOC in the elf file.

The most promising thing we tried (that didn't work)

One thing we tried was to do a two stage build, where:

1. we produce an object file with debug info
2. use objcopy to mark it as ALLOC
3. then do a final linking step

This looks something like this:

zig build-obj -O Debug \
	-fno-strip \
	-target x86_64-freestanding \
	-mno-red-zone \
	main.zig
objcopy --set-section-flags ".debug*"=alloc main.o
zig build-exe --name main -fno-strip -T linker.ld main.o

The linkerscript is there to export the addresses of the debuginfo sections to be consumed by the program at runtime:

ENTRY(main)

SECTIONS
{
	/* begin putting sections at 1 MiB */
	. = 1M;

	/* Executable code */
	.text : ALIGN(4K)
	{
		KEEP(*(.multiboot))
		*(.text)
		*(.text.*)
	}
 
	/* Read-only data, e.g. strings */
	.rodata : ALIGN(4K)
	{
		*(.rodata)
		*(.rodata.*)
	}

	/* DWARF debug info */
 	.debug_info :
	{
		__debug_info_start = .;
		KEEP(*(.debug_info))
		__debug_info_end = .;
	}

        ...
 
	/* Read-write data (initialized), e.g. globals */
	.data : ALIGN(4K)
	{
		*(.data)
		*(.data.*)
	}
 
	/* Read-write data (uninitialized) and stack */
	.bss : ALIGN(4K)
	{
		*(.bss)
		*(.bss.*)
		*(COMMON)
	}
}

This exports __debug_*_{start,end} constants that can be used to make slices of the debuginfo sections like so:

extern var __debug_info_start: u8;
extern var __debug_info_end: u8;
const debug_info_size = @ptrToInt(&__debug_info_end) - @ptrToInt(&__debug_info_start);
const debug_info = @ptrCast([*]u8, &__debug_info_start)[0..debug_info_size];

...

Now, this successfully gets the debuginfo loaded into memory at runtime, with the correct addresses to the dwarf sections and everything. However, this turns out to not work because the relocations inside the debuginfo are not processed. (verified using llvm-dwarfdump)

(In fact from what I can tell, the relocation code in LLD seems to have a hardcoded assumption that ALLOC sections and debuginfo sections are mutually exclusive.)

Another thing we were considering is using something like split debug info, and then using a two stage build to include the debuginfo into the final binary. But this would have the issue that the debuginfo would be stale.

Reproducer/minimal setup for experimentation

Here is a paste.

Note that the objcopy invocation breaks gdb as well (for the obvious reason).

What we want

I think it'd be nice if there was a linker option or something along those lines to make the debug info in a zig binary marked as loadable. I'm not sure how feasible this is with lld, but I'm filing this hoping that the zig linker can meet this use case.

The remaining issue would be of API design: specifically, there's a runtime component in the form of the variable bindings with the debuginfo pointers. My uninformed proposal is that there could be something like std.builtin.debuginfo.section_name, and you could conditionally do something like @hasDecl(std.builtin, "debuginfo") to see if it is there.

Thanks!

[RossComputerGuy]

👍 from me, also better debug info on UEFI would be very useful.

[sfiedler0]

Any updates on this? It would be great for bigger Zig embedded projects / kernels.

About the idea with std.builtin.debug_info.section_name: As names are resolved at compile-time (before the debug info even gets written; that happens while linking or emitting object) making the debug info accessible through std.builtin.debuginfo.section_name (or whatever) before it gets written is difficult.
What would be good though is some function getFreestandingDebugInfo() that takes all addresses and returns something useful.
Or that function takes a pointer to a buffer (instead of returning it) where the debug info can be written to (because we all know about pointers to stack memory). Or it just accepts an allocator. Or whatever.

[benburkert]

I was able to get this approach mostly working with a couple changes to std.debug.Dwarf, there seems to be an issue with the return address on panic but i think that may be a riscv issue. I wrapped it up into a module here: https://github.com/benburkert/freestanding.zig

The changes were related to how offsets are calculated within the debug info, but i'm not well versed in elf/dwarf enough to say if this is the correct way to calculate offsets. If it is, i'd be happy to upstream this, but i'm not sure how to write tests for it either.

[sfiedler0]

If I understand it correctly, there are some sections that need absolute addressing and some that need relative addressing (offsets). Some code about that one is in this blog post by Andrew Kelley (note this was old zig code, new one is entirely different):

    S.self_debug_info = std.debug.DwarfInfo{
        .dwarf_seekable_stream = S.seekable_stream,
        .dwarf_in_stream = S.in_stream,
        .endian = builtin.Endian.Little,
        .debug_info = dwarfSectionFromSymbol(&__debug_info_start, &__debug_info_end),
        .debug_abbrev = dwarfSectionFromSymbolAbs(&__debug_abbrev_start, &__debug_abbrev_end),
        .debug_str = dwarfSectionFromSymbolAbs(&__debug_str_start, &__debug_str_end),
        .debug_line = dwarfSectionFromSymbol(&__debug_line_start, &__debug_line_end),
        .debug_ranges = dwarfSectionFromSymbolAbs(&__debug_ranges_start, &__debug_ranges_end),
        .abbrev_table_list = undefined,
        .compile_unit_list = undefined,
    };

[sfiedler0]

Still not fixed with #25227 . Except now I don't anymore get a "BufferTooSmall" or whatever error, but instead get a panic with "integer overflow" caused by some standard library code.

[sfiedler0]

Update: I have tried locally (with GDB backtracing for finding the relevant places in std) to replace all offsets for debug_abbrev, debug_str and debug_ranges with 0. This part works now (however, I just hacked that thing together, so idk if that can be upstreamed).
Now I have problems with actually capturing the stack trace.