Implement libunwind in Zig

[alexrp]

In our vendored libunwind, there are approximately 15k lines of implementation code. We have to keep the headers for C/C++ code that uses them, but it seems quite feasible to rewrite the implementation in Zig.

This could even be done incrementally following a similar model to #2879.

High-level list of tasks to be done here.

[nektro]

is there an existing testing strategy to ensure the new Zig implementation is as correct as the C++ one?

[nektro]

i see https://github.com/llvm/llvm-project/tree/main/libunwind/ has a test folder
edit: doesn't seem particularly comprehensive at first glance

[allocgator]

Would it be possible to break this down into smaller sections - something along the lines of this and this ?

[alexrp]

Would it be possible to break this down into smaller sections - something along the lines of this and this ?

I'm not familiar enough with the internals of libunwind to give a great answer, but here are some very high-level tasks that need doing:

• Port the libunwind test suite to the Zig build system and make sure that it passes as a baseline.
• Set up frontend logic to build libzigunwind (alongside libunwind for now; see libzigc logic).
• Scaffold the Zig implementation with weak exports matching the full libunwind ABI.
  • Mainly to get an overview of what needs doing; each function can @trap() initially.
  • Each function should be turned into a strong export once the corresponding libunwind function has been fully ported and deleted.
• Port all the personality function implementations to Zig.
• Get stack unwinding for x86_64, aarch64, arm, and wasm working:
  • Implement DWARF unwinding.
  • Implement Darwin unwinding (DWARF + compact info).
  • Implement Windows SEH unwinding.
  • Implement Arm EHABI unwinding (32-bit Arm only).
  • Implement WASM unwinding.
• Thoroughly fill in all the arch/OS-specific details in the implementations above.
• Extremely low priority: Implement SjLj-based unwinding.
  • I doubt anyone even uses this.
• Finally, delete the vendored libunwind so that the frontend only builds libzigunwind.

[tensorush]

Not sure if it helps with this, but I've reimplemented build.zig for libunwind from scratch.

Test suite seems to build.

https://github.com/allyourcodebase/libunwind

[tensorush]

I'd been looking into getting this port off the ground and came across a few things I wanted to clarify:

1. How to determine which exception handling mechanism (DWARF_EH, SEH or SJLJ) is enabled? C/C++ code does it by checking defines like __SEH__. What's the preferred way for Zig?

2. What's the preferred way of calling compiler intrinsics like _get_ssp, _inc_ssp and __gcspopm from src/cet_unwind.h. The same way, by @cImporting the necessary C headers, or some other way?

[alexrp]

How to determine which exception handling mechanism (DWARF_EH, SEH or SJLJ) is enabled? C/C++ code does it by checking defines like __SEH__. What's the preferred way for Zig?

Figure out how Clang defines those, and do the equivalent detection in the libunwind Zig implementation based on @import("builtin").

What's the preferred way of calling compiler intrinsics like _get_ssp, _inc_ssp and __gcspopm from src/cet_unwind.h. The same way, by @cImporting the necessary C headers, or some other way?

We don't really have meaningful support for CET at the moment. I would say just don't worry about it for now; this is a problem to be dealt with if/when we add that support.

[tensorush]

Alright then, I'll be trying to get a minimal unwinding implementation up-and-running on 64-bit Darwin with just DWARF exception handling and without shadow call stack protection (CET/GCS). I'll report on progress in a week, or maybe right after 0.14.1 release.

Btw, there's this curious arch supported by libunwind called OpenRISC 1000 (or1k) which I don't see among the ones supported by Zig. I can keep it's code, but I was wondering if it's going to be added.

[alexrp]

Btw, there's this curious arch supported by libunwind called OpenRISC 1000 (or1k) which I don't see among the ones supported by Zig. I can keep it's code, but I was wondering if it's going to be added.

It would be nice to. LLVM doesn't support it, but it's alive and sees development in the GNU ecosystem. It's not unthinkable that Zig might gain self-hosted support for it in the future.

However, it will require some std.Target bits to recognize it. I can put up a PR to do that soon-ish.

[tensorush]

In case anyone is interested in collaborating on this, I've created a repo on Codeberg:

https://codeberg.org/tensorush/libzigunwind