[Bug] Breaks in multiple ways with rust binaries with debug symbols left in

[winneratwin]

this is a combination of the gdb python bindings being bad and the fact that PINCE doesn't have support for languages with no void types

GDBCommandExtensions.py line 23 breaks because the gdb python bindings can't convert &str types (which environment variables are cast to in rust) to strings you can fix it by replacing .string() with .format_string().strip('"')
same for ScriptUtils.py line 22 and 23

if you fix those lines you get a new error at ScriptUtils.py line 33 since it tries to get the void type but fails since rust has no void/null type and even if you comment it out it fails at a more systematic level where RegisterLabel.py line 29 is erroring with this error can only concatenate str (not "NoneType") to str which i am assuming is it trying to do something with the void type at which point i gave up trying to fix PINCE and decided to make an issue

[korcankaraokcu]

languages with no void types

Completely slipped my attention, thanks for the bug report. I'll look into this soon

[brkzlr]

I don't think this has to do with whether a language supports void or not as I tested it on a Go binary, where Go also doesn't have a void type, and no issues occur.

I think this has more to do with gdb's python binding that has poor support for Rust more than the void-ness of a language.

[korcankaraokcu]

Tested with a simple, infinitely looping rust binary with debug info. .format_string().strip('"') doesn't fix anything, GDB can't read the path var at all, printing the variable gives <error reading variable: Cannot access memory at address 0x8>

[korcankaraokcu]

I've solved the void pointer issue with changing this code In ScriptUtils

void_ptr = gdb.lookup_type("void").pointer() to void_ptr = gdb.lookup_type("u8").pointer()

It works if we use u8 instead of void. But again, it fails in many places that uses C-like expressions, such as breakpoints and watchpoints. Maybe it's about the time to refactor the older codebase to use more generalized expressions. However, this might take a while

[korcankaraokcu]

Here's something interesting, none of these issues appear if the target is compiled in release mode

[korcankaraokcu]

Considering all other issues, such as not being able to read string variables and all. I think the best solution would be to make GDB act like it's a release binary instead of trying to fix every single edge case out there