Looking up source files in the IDE is done via Codetools. That is because files could be open already. Or sometimes need to be found in some path of a package.
However, gdb gives you the filename, and also a path (depending what fpc put in there). So if you are not in the IDE, and don't care about files belonging to packages, you just take what gdb gives you, and look it up on disk (you need the include paths for all files that you want to find).
Ok, a few tips. And background on the gdbmi backend.
1) If you send a cmd to gdb, then you need to wait for the response.
The code in gdbmi debugger does that in a loop, using ProcessMessages.
- Pro: You call the code (first "SendCmdLine", then ReadCmdLine" until you got the full result. That means you can write your code linear, no need to have events....
- Contra: Because you sit in a loop, you can not interrupt it. If the debugger sits in a "ReadCmdLine" loop, and the user presses a button, that should stop the debugger, there is a problem. Because the debugger can only stop when it exits the loop. So you need to schedule event then, and it gets real complex (If the user exits the IDE, while the debugger is running, it gets real complicated. The exit has to be stored as flag, and later resumed....
Also on a higher level all debugger stuff works as event. So the IDE does not hang.
That is why I recommend the LLdbCode.
It has a queue for command (here lldb, but can be gdbmi), and triggers a callback/event when the result comes back from gdb. So the code does not get stuck in nested calls.
Another thing is that you often need more than one command to get data from gdb. For examples for locals you need to set thread and stack. (the lldb queue has some support for this).
Or you need ptype and --data-evaluate, ....
For that it makes sense to have an outer queue (as both gdbmi and lldb have).
A command in that queue then has a specific task, and gets all the data it needs.
=> So in both debuggers you see some T....DebuggerCommand => that is what drives the calls to gdb.
Mind that (not yet done in the IDE) the outer queue could run more than one command in parallel, allowing the inner queue to sort commands by thread and stack, to avoid extra switching (speed up).
Last not least, depending on which platform you target, you can use fpdebug instead of gdb.
But the dis-assembler is not as complete as the one from gdb.