GDB 10.2 for Haiku:
GDB 10.2 for Haiku:
Is it actually working? Can it debug Haiku executables?
As @X512 also just said, does this version ‘actually’ work? The previous GDB version was unable to debug executables for 64 bit and it would be very interesting to see if it actually does work and can debug apps properly.
Just because it compiles fine doesn’t mean it works well.
Just out of curiosity: would a working GDB have any advantages over Haiku’s debugger?
It’s not about the benefits. GDB will enable debugging in ported IDEs. QtCreator for example.
I do most debugging with logging and stack traces that are available in crash reports and my SystemManager utility.
I actually like Haiku debugger. It allows GUI insertion of breakpoints, variable inspection, stepping through code, it’s really a great piece of software which I use daily. Once it’s started, it is very fast. My only gripe with Debugger is the inability to interpret STL containers, but there is nothing stopping me (or anyone) from contributing patches. As Gerasim pointed out, the ability to integrate with QtCreator is probably the biggest benefit to Haiku community to have working gdb.
Just compiling it will, in fact, not work at all. The reason for that is that the interfacing between the debugger and the debugged application is platform specific. We had implemented it in an old version of gdb, but the patch was not easy to maintain and we never updated it. I think you can still find it on haikuports.
Gdb is still useful in other cases however: I have used it for remote debugging on embedded systems with openocd, for example
cocobean, I’ve just tried that version, and it fails to actually “run” the application. Gdb starts and appears to be working, but when you type “run” you get the “Don’t know how to run. Try help target” error. Setting b 2 and it appears to set the breakpoint correctly, so it’s almost “working”.
Haiku-specific kernel debugging interface is probably not implemented.
Your reasoning is correct, it is a known and expected behaviour.