Stack unwinding for the masses

[LemonBoy]

TLDR

Backtraces are now fully functional in release mode! 🎉

Since the stack-walking strategy is not that reliable and since libunwind is always (? or most of the times? I didn't figure out that yet) linked in anyway why not use it?

This brief weekend project is my first attempt at writing some Zig code so please bear with me if the code is not that nice.

You may ask why I didn't roll my own unwinder... well I've got halfway trough (the whole eh_frame was perfectly parsed and all the opcodes executed) when all of a sudden I've realized that using libunwind would've been a better use of my time.

At the moment it's only been enabled for linux but should work pretty well on Apple's systems and/or BSDs, YMMV of course.

[andrewrk]

This is undeniably useful.

However, I think that relying on libunwind is a local maximum. (I realized that it's not always clear exactly what I mean by that, which is this).

The problem is that, although zig ships with libunwind for the purposes of cross compiling, for some targets, libunwind is provided by the system, not by Zig. That means we don't control the implementation, and we don't control these important factors:

• whether it allocates memory with malloc/free. This interferes with 2 use cases:
  • if libc malloc became corrupted and we still want to print a stack trace
  • using a preallocated memory buffer for stack traces, to make them work in low memory conditions
• whether it is signal safe, which interferes with segfault handling (in debug builds, detect stack overflow at runtime and output a partial stack trace #1915)
• trying to solve stack trace unwinding/printing when stack overflow occurs (also in debug builds, detect stack overflow at runtime and output a partial stack trace #1915)
• whether the code works on freestanding or not. Currently the debug info code does work on freestanding and I have written a blog post about this.

Even for the implementation of libunwind that zig ships, it's just vendored code from upstream. I would like to avoid forking it. That means either way, we don't really control the implementation.

Ultimately, I think it will be worth it to have a competing implementation of stack unwinding, because it will allow us the flexibility to support these situations that require tight control over the implementation.

[LemonBoy]

Ultimately, I think it will be worth it to have a competing implementation of stack unwinding, because it will allow us the flexibility to support these situations that require tight control over the implementation.

Yeah, I already have some code ready along with other niceties such as cross-library DWARF parsing that I'm slowly but steadily working on (and is blocked by #2354).