RadDebugger and Zig

Help
,
1

Now that RadDebugger (alpha) is available for Linux I gave it a try on my Zig project. It is incredibly fast and smooth but I couldn’t find a way to make it usable with Zig types. I immediately went to see how will it handle MultiArrayList but it only shows ptrs, len and capacity raw fields and I couldn’t find a way to make it give me a usable view. I tried also casting the ptrs using C like syntax but since the type I want to cast to in Zig is my_namespace.MyType it complains how my_namespace doesn’t have a member called MyType.

Anyone knows of some tricks to make RadDebugger more usable with Zig? Also do you think it is worth opening issues on their github about Zig specific problems since I couldn’t find any at the moment.

2

For some reason I didn’t find your post when searching here for “rad debugger” before posting RAD Debugger with "preliminary support for native Linux". Bumping your thread in favor of mine.

3

I use raddebugger on windows as my daily driver. You can add type views in the “Type View” tab, but I don’t remember how to do it anymore and lost it all my types views when my HD died; if you go to ryan fleury on twitter you might be able find to some examples of he uses it;

Edit: a Type View for zig slices will look something like this type: []? expression array(ptr, len)

To inspect complex types raddbg provides a “raddbg_markup.h” that you can at compile time generate type views for your types, if I not mistaken Odin already creates this for you. In my opinion this is your best bet at getting a proper view at MultiArrayList;

Edit2: You can for instace use this function to create views at comptile time

fn raddbg_type_view(comptime id: []const u8, comptime type_match: []const u8, comptime expr: []const u8) void {
  comptime {
    _ = @export("type_view: {type: ```" ++ type_match ++ "```, expr: ```" ++ expr ++ "```}", .{
      .name = "raddbg_data__" ++ id,
      .linkage = .strong,
      .section = ".raddbg",
      .visibility = .default,
    });
  }
}

For instance call raddbg_type_view("0", "[]?", "array(ptr, len)"); anywhere in your code, I don’t think zig can generate unique numbers to we use as name

I almost only use array(pointer, len) in the Watch window, to inspect my types. But be aware that when debugging many of your variables will be unwatchable:

  1. Function args always work
  2. const declarations like in const x = foo(); are likely to be unwatchable
  3. var declarations works, but they must have unique name inside the function scope for instance having 2 for(0..N) |i| ... loops inside your function will make i mostly likely to be unwatchable, don’t ask me why
4

https://m.youtube.com/watch?v=rcJwvx2CTZY might help you with type views (not sure - watched it yesterday).

5

Zig has similar constructs for lldb, so maybe they would accept a PR that adds it to MultiArrayList or Hashmap?

6

Really? With raddbg running on linux I think is worth open a issue or a PR for; please link it here if you do!

7

https://codeberg.org/ziglang/zig/src/commit/8f87dfa9c2812a473468f88184b8f905f4df60d0/lib/std/multi_array_list.zig#L684

the “code” is a bit mysterious since it’s just a function declaration, but it forces the compiler to expose information about internal details, then LLDB zig plugin read that and computes offsets to interpret the MultiArrayList.

Lldb plugin llvm-project/lldb/source/Plugins/Language/Zig/ZigLanguage.cpp at e0a42bb343616608f4fdd1284246f82b0d3029d7 · jacobly0/llvm-project · GitHub

maybe this info is actually enough already for Rad ? IDK

8

I didn’t know about that LLDB plugin but I used a slightly modified pretty printers python script available under tools dir (seems its under lib/lldb/pretty_printers.py now) in the zig repo to make it work in LLDB for some time now and it is really helpful. That is why I immediately tried to setup the same in RadDbg but didn’t manage it.

I looked a bit at the type views and I didn’t see an obvious way to solve this but haven’t really tried hard yet :slight_smile:.

9

I opened a ticket about this to RadDbg. You can check it out here and if you are able add any other useful info. Thank you.

10

There is an N x M problem here - N languages, M debuggers. That’s why I don’t think it would make sense to tie the zig std lib directly to RAD debugger, i.e. by putting raddbg_type_view directly into the std lib, because it’s just one of many third party debuggers. However, if there were some defensible attempt at a standard, even if it were by RAD folks themselves for instance, then it would be reasonable to have the standard library provide that debug information by default. I would love it if RAD or some other third party would do this. However, if no one else steps up to reach this bar of quality, it will fall upon ZSF to create and steward such a standard, as well as a debugger to go along with it. We’re already essentially doing that with jacobly’s LLDB fork.