Breakpoints trigger in VS2019 (16.4.4) but not in RemedyBG 0.2.8.5

JesseMeyer

Jesse

64 posts

Programmer at NASA GSFC

#21723

Breakpoints trigger in VS2019 (16.4.4) but not in RemedyBG 0.2.8.5

4 years, 6 months ago Edited by Jesse on October 18, 2019, 1:13pm

Hi,

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

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

x13pixels

311 posts / 1 project

None

#21724

Breakpoints trigger in VS2019 (16.4.4) but not in RemedyBG 0.2.8.5

4 years, 6 months ago

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

x13pixels

311 posts / 1 project

None

#21776

Breakpoints trigger in VS2019 (16.4.4) but not in RemedyBG 0.2.8.5

4 years, 6 months ago

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

JesseMeyer

Jesse

64 posts

Programmer at NASA GSFC

#21781

Breakpoints trigger in VS2019 (16.4.4) but not in RemedyBG 0.2.8.5

4 years, 6 months ago Edited by Jesse on October 18, 2019, 1:12pm

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.