Forum > Debugger
Debugger development
Shpend:
@PascalDragon
Hmm, Do you guys have any other alternatives over to GDB? Or do you just stick with it and try to improve it over and over? Maybe learning Debugger development could be something I could help, well I need to learn that too, but this is IMHO far easier than compiler-development, in strict comparison. Maybe the GDB should get at some point a rewrite, or "rework" in some areas to be easier in the points it currently isn't easy. Any suggestions from you guys to that, maybe where I would/could start learning effective Debugger-Development?
Martin_fr:
Edit: This topic was originally part of https://forum.lazarus.freepascal.org/index.php/topic,53069.0.html and has been splitted out to its own thread
--- Quote from: Shpend on January 30, 2021, 07:04:42 pm ---@PascalDragon
Hmm, Do you guys have any other alternatives over to GDB?
--- End quote ---
Yes, there now is FpDebug.
And the IDE also supports lldb.
GDB is not actually bad. It is a great debugger. And even for use within a frontend it has the "mi" interface to allow other applications parsing gdb output.
Yet still, its Pascal support is limited. And still the IDE has to communicate via pipes to stdout/stdin, encoding all its queries into gdb commands. The results are Gdbs C driven idea of Pascal.... (Not entirely GDBs fault though, some Pascal features are not easily represented/distinguished in Dwarf/Stabs)
FpDebug is a complete debugger in Pascal for Pascal.
It was started in 2006 by Marc. Development was on and off by various people. In the past few years, Joost and I put some work in it. And now it is finally use-able (i.e. it has most of the features that the gdb based debugger has).
It is included in 2.0.x => package LazDebuggerFp.
https://wiki.lazarus.freepascal.org/Debugger_Status
The entire topic, what works or not and why... All that is rather complex.
For a debugger to work, you very simplified need:
- Compiler support
- Debuginfo format support (i.e. Dwarf/Stabs)
- Debugger backend (gdb/lldb/fpdebug) / OS support / Hardware support
- Frontend / IDE support.
Martin_fr:
--- Quote from: Shpend on January 30, 2021, 07:04:42 pm ---@PascalDragon
Maybe learning Debugger development could be something I could help, well I need to learn that too, but this is IMHO far easier than compiler-development, in strict comparison. Maybe the GDB should get at some point a rewrite, or "rework" in some areas to be easier in the points it currently isn't easy. Any suggestions from you guys to that, maybe where I would/could start learning effective Debugger-Development?
--- End quote ---
My last post was however not meant to say there are no easy points to start with.
One starting point could be the front end.
It has been long neglected. Now that we have a better backend, it could do with some work.
Look at the watches and local dialog. It would be cool, if
- watches for structures (class/record) had a + box in front of them. So they could be unfolded, and display a line for each member. (for large structure have a filter, or field picker)
- same for arrays
- "instance class" instead of "declared class" should be easier accessible.
And could be "on" by default, if we had a global option for that.
- re-order watches in the watch window.
There is lots more in the front end. (memory dump window, multiple inspect windows, fix inspect window does not always update on stack frame change, improve stack view window, ........)
In doing this, you would get to know the current "dbg-interface". Which frankly is lacking any design at all. It was just ripped out the old gdbmi code.
Improving this, would give a glance into the various backends.
There also are the global options (Tools / Options). They could be displayed much nicer. And there is more work to be done on "per project" settings.
If you want to dive in at the deep end, then that is either the gdbmi, lldb, or gdbmi backend. There is plenty to do. But it is the deep end of the pool.
Here you need your pick, which backend.
- For local debugging (Intel - Win/Linux/ and someday Mac) FpDebug will be taking over.
- But Gdb/Lldb will remain, and be maintained. It still has some areas where it beats FpDebug, and it is needed for remote debugging (even though fpdebug will some day do some of the remote too). Gdb is also used for targets other that the ones indicated above).
If you are eyeing any particular feature... ask.
PascalDragon:
--- Quote from: Martin_fr on February 02, 2021, 07:16:05 pm ---Look at the watches and local dialog. It would be cool, if
- watches for structures (class/record) had a + box in front of them. So they could be unfolded, and display a line for each member. (for large structure have a filter, or field picker)
- same for arrays
--- End quote ---
More often than not this would be great for the hint window as well. ;D
Shpend:
@Martin_Fr
I would love to most likely work on your new FP_Debugger-Frontend for now, since to put it frankly, this would be my 1. touch on Debugger-Coding ::) since this shall be the future of FPC where you have already the compiler, the IDE, and finally the debugger itself written in pure FPC. Of course, the further my experience goes and the better I get at developing the debugger-frontend the higher the chance I will then dig deeper into the backend. But as mentioned, for now, I will spend my time and focus on the frontend.
Can you direct/guide me a bit where Can I find the specified .pas files for the frontend of the FP_Debugger, since it's quite large, and I would like to know where exactly I should start the coding.
Generally, many thanks for this topic generally, martin. I will make a list of your already written notes and see on the fly, while I am developing if I should/can add more to that list, regarding of course here still the frontend.
@Pascal_Dragon
I will add this to my list too haha.
Navigation
[0] Message Index
[#] Next page