Jesse
64 posts
Programmer at NASA GSFC
Breakpoints trigger in VS2019 (16.4.4) but not in RemedyBG 0.2.8.5
Edited by Jesse on
Hi,

I have a simple Zig program that can be successfully debugged by VS2019 but not by RemedyBG.

  1 2 3 4 5 6 7 8 9 10 const std = @import("std"); pub fn main() !void { // If this program is run without stdout attached, exit with an error const stdout_file = try std.io.getStdOut(); // If this program encounters pipe failure when printing to stdout, exit // with an error. try stdout_file.write("Hello, world!\n"); } 

The problematic behavior is clear to see below. For some reason, RemedyBG cannot manage to find the breakpoints placed on those lines of code while VS2019 can.

I know the majority of users who use RemedyBG do so to debug C code, but given that VS2019 can work with Zig PDB files, I think RemedyBG should too. Do you consider this a bug to be fixed?

https://vimeo.com/366008013

https://vimeo.com/366008003

I have sent a zip file containing the Zig code and pdb files to your email. This thread is for public awareness.

Thanks,
Jesse
265 posts / 1 project
None
Breakpoints trigger in VS2019 (16.4.4) but not in RemedyBG 0.2.8.5
Jesse,

I will certainly take a look. Thanks for taking the time to report the issue.

As an aside, the vimeo links in your post don't seem to be working.

Thanks!

--
George
265 posts / 1 project
None
Breakpoints trigger in VS2019 (16.4.4) but not in RemedyBG 0.2.8.5
Jesse,

Looks like the issue is that Zig is outputting line information for the 'main' function in hello.zig twice to the PDB.

Line information for the function 'main' shows:

• Line number: 3; offset: 0x00
• Line number: 5; offset: 0x0a
• Line number: 5; offset: 0x1e
• Line number: 8; offset: 0x4c
• Line number: 8; offset: 0x60
• Line number: 3; offset: 0x82 <- unexpected

RemedyBG's problem is that it uses the first and last entries as the range of lines for a function (this seemed like a reasonable thing to do). This means the range for 'main' ends up being start: 3 to end: 3. I can change the code to compute the proper range.

BTW, it looks like Visual Studio appears to pick the second entry when you put a breakpoint on line 3. This is why it breaks on function exit and not at the beginning of the function like you would expect.

Thanks.

--
George
Jesse
64 posts
Programmer at NASA GSFC
Breakpoints trigger in VS2019 (16.4.4) but not in RemedyBG 0.2.8.5
Edited by Jesse on
I have a hunch as to why. In Zig, the 'try' keyword is short hand for what amounts to the following C code.

 1 2 3 if (ptr == null) { return error_null_ptr: } 

The ! symbol preceding the void type enforces that an error union will be returned by the function. Try is the mechanism here that returns the error in such a case. So those lines do more than one task. They check that the values are valid, and if they are, they perform a function on them, else return an error. So each of those 'try' keywords appear to get their own line in the PDB file (one for the function call and the other in case of return?). I'll post this forum post over at the Zig GitHub and see if multiple PDB entries is desirable, since it doesn't appear to help debugging, or those building debugging tooling.