Hi,
I have a simple Zig program that can be successfully debugged by VS2019 but not by RemedyBG.
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
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
Edited by Jesse
on
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:
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
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
I have a hunch as to why. In Zig, the 'try' keyword is short hand for what amounts to the following C code.
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.
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.
Edited by Jesse
on