Maybe it was already raised :
I have a simple C++ program generated with Genio and I want to start debugging with the default debugger.
Even if the program is compiled with debug symbols :
The source code is not displayed in Debugger :
Same executable via QtCreator/GDB : everything is fine :
Am I missing a step for the default Debugger or is it a known bug ?
Which type were the debug symbols ? I think Haiku´s debugger still has some difficulties with DWARF5 type
Native debugger has bugs and unimplemented things, a lot of things need to be fixed.
Native debugger has bugs and unimplemented things, there are a lot of things that need to be fixed.
To fix bugs, you would have to use GNU Debugger to fix Native Debugger.
That’s nonsense.
If you have issues like this.
Please open a ticket at htpps://dev.haiku-os.org
Let me check with a working example versus this case.
But indeed I will open a ticket if I find something interesting.
Ok a ticket has been created, I have again reproduced the issue.
The native debugger has bugs and limitations, so anyone who wants to fix bugs should use gdb to code the native debugger. Is there another way to fix bugs in the native debugger?
I talked about the obvious problems that are common knowledge, and they have been reported by @trungnt2910 , @X512 and @KENZ.
Just read here:
Posts on the forum are not common knowledge. Tickets or it didn’t happen. There is no point in telling people “oh that is known” when nobody told the developers. You can keep your bugs forever in that case.
GDB is not required to work on any haiku applications, including Debugger.
Yes, using good old printf.
The native debugger has some minor annoyances, but several developers of Haiku and applications have been happily using it for years (otherwise, they would have been annoyed enough, and fixed the bugs).
With gdb only being available for two months, how do you think we got around to working on Haiku for the past 10+ years?
You can of course use the native Debugger to debug itself.
I was talking about fixing bugs initially, the issue is that the native debugger is the only tool available, people adapt to the problems and limitations, until it improves or there is a better tool.
Or maybe they just improve Debugger as needed? That seems the easier option to me. It will not magically improve if people don’t put time to work on it…
Improvements would be in DWARF.
Do you have specific bugs to report? As far as I know, there were some problems a few months ago after a gcc update, and then one of the developers implemented the required parts of DWARF to get things working again.
But now, “Debugger is broken” remains stuck in people’s idea, despite the issue already being fixed.
Again, for debugging native apps, you can use Debugger as we have done for several years while no gdb port was available. gdb has its use, for example to debug code compiled with other compilers that Debugger may not handle very well yet. But you can use debugger to debug itself, or any other Haiku native app, just fine.
Maybe the problem encountered by the OP was due to the flags used by Genio to compile the test app ? Wrong debug info format, only partial, etc ?
Has anyone already opened tickets for this problem!
I have recently seen that Debugger displayed wrong source code position (GDB worked fine in the same case). Debugger also can’t be used for large programs, it crashes with out of RAM or other reasons. It is also deadly slow compared to GDB.
I expect that it is very complex task that currently nobody attempting to do. It is not something that can be done in GSoC period. I think that making native GUI backend over GDB is a better idea.
Did you report bugs? Otherwise, why would people be working on it?
Did you take a look at the sourcecode to decide that it is very complex?
Your statement are very negative and I think will discourage other people from even trying. Maybe not what you intended, but that’s how it sounds to me.
So, how did you came to conclusions such as “it can’t be done in GSoC period”? And also, how is that an useful metric? We know GSoC students are typically quite slow (because they are beginners and don’t know the project) and GSoC projects need to be small and well defined.
Maybe the discussion has diverged from my initial post : I’ve noticed some strange results in the default Debugger versus GDB.
Not sure if it was already raised since Beta 5 that’s why I’ve created the below ticket :
https://dev.haiku-os.org/ticket/19243
Maybe if additional people want to share their findings, just put some comments in this ticket ?
Default Debugger is working fine in some situations but when it failed to do the job my current workaround is to move to QtCreator for the GUI and GDB for the backend:)
@PulkoMandy in response to your questions…
I’ve personally seen the issue that the debugger doesn’t know how to map from the current IP back to the source code. And searching for symbols I know are in the binary doesn’t work. This is obviously the lack of Dwarf5 support.
I also looked into the dwaft parsing code to try and work out where it was getting lost. But it was taking too long for me to understand it. And then the GSoC for gdb came along and I decided to just use gdb instead.
The IDE that I wrote has a simple front end for gdb that I developed under Linux. Over the last few weeks I’ve been adding support for a ssh backend to the IDE such that the debugger, symbol search, file read/write and grep etc. It’s a kinda like using vscode’s remote ssh support… but you know more boutique. And buggy. So yeah I’m actually debugging stuff from the Windows build of the IDE over ssh to a Haiku b5 VM. And it works fine. Once the IDE is a little more robust in Haiku itself I’ll be able to run it natively. Including debugging child processes with gdb.
