Forum > Packages and Libraries

can't figure out how to use lazdebuggergdbmi in ubuntu 20.04

(1/1)

yanes19:
Hi all ,
I was looking to the package and other use examples on the internet for days now ,
I want to make simple front-end program that runs the debuggee  under GDB , breaks at certain address , and then read procedure assembler from there , which is fairly simple task to do in a gdb terminal session ,
I can't figure out any way to start or use the package ,
so please before I find my self re-inventing the wheel  , can someone points to a working example or a good documentation to start using the gdb-mi interface ??

best regards &
thanks in advance
Yanes

Martin_fr:
Just to be sure: You want to write your own debugger front end. You do NOT want to use the IDE watches window etc?

For what currently is in place: https://wiki.lazarus.freepascal.org/Lazarus_Debugger_Implementation

Now there are 2 ways to do your own....

1) Tell the gdbmidebugger to return the assembler for an address range (you do NOT send your own commands to gdb)
For that you need to create lots of classes in your app. Best to start by looking at the test case, and the code in /debugger

2) If you want to send your own gdbmi
Look at TCmdLineDebugger components\lazdebuggergdbmi\cmdlinedebugger.pp

And TGDBMINameValueList to parse results.

Note that TLLDBDebugger has a new implementation of CmdLineDebugger. It does work more event driven, instead of hanging in App.ProcessMessages.
This avoids various problems further down the line.

yanes19:
Thanks for your reply
I really appreciate that after days of research

--- Quote from: Martin_fr on August 20, 2021, 09:17:41 am ---Just to be sure: You want to write your own debugger front end. You do NOT want to use the IDE watches window etc?

--- End quote ---
Yes, no for the two statements respectively , I want my totally independent program to use at assembler code level , I don't care for dwarfs, source code (pascal or other ), or  debugging symbols ,I'm willing to use for any native binary (i386/amd x64 native machine code).
 


--- Quote from: Martin_fr on August 20, 2021, 09:17:41 am ---1) Tell the gdbmidebugger to return the assembler for an address range (you do NOT send your own commands to gdb)
For that you need to create lots of classes in your app. Best to start by looking at the test case, and the code in /debugger

--- End quote ---
I looked at all available sources that came with lazarus ide and it seems little dependant on the ide units or the pascal source in the first place ,
so these will be super heavy to include in my program .

2) If you want to send your own gdbmi
Look at TCmdLineDebugger components\lazdebuggergdbmi\cmdlinedebugger.pp

And TGDBMINameValueList to parse results.
thanks for pointing these out , will definitely take another look .

best regards

Martin_fr:
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.







Navigation

[0] Message Index

Go to full version