On 21/11/2018 10:58, Dimitrios Chr. Ioannidis via lazarus wrote:
I would like to be involved / help as I am thinking implementing the
mEDBG protocol and intergrate it to Lazarus to debug AVR MCU's using
this debugger https://hackaday.io/project/162372-xplained-yourself .
I already tried to use the avr-gdb --> avarice --> dragon -->
atmegaxxx combination ( which worked in Linux but not in Windows ) and
the result is that I have 3 bricked mcu's ( most probably by flashes
has been worn out by software breakpoints) . Not even the HVPP
procedure restore them.
Anyway if I can help ( and learn at the same time the Lazarus /
Debug internals ) that would be awesome.
The Debugger in Lazarus consists of 2 layers (plus the external exe, if
based on one)
The presentation and IDE control: DebugManager/DebugBoss
The BackEnd: LazDebuggerGDBMI, and others.
You would need a new backend.
Backends are based on the DebuggerInterface components\debuggerintf\...
This is not yet documented. (And may still be subject to small changes).
[Actually someone started to put something on the wiki, I dont know if
that has gone anywhere ...., I recommend to look at example code, see below]
The easiest way for you is to look at an existing implementation, and
replace the communication with the external exe.
The "simplest" available is:
components\lazdebuggers\lazdebuggerlldb\lazdebuggerlldb.lpk
And you can go back in SVN to its initial revisions, to get an even
simpler version.
Depending on how your external exe works, you need some sort of control
when to send which message, and how to parse the answers...
"lazdebuggerlldb" has 2 internal queues:
- One in commandline debugger, which controls sending individual
commands, and waiting for answers.
- One in the main lazdebuggerlldb, which is hard to explain: The truth
is, it shouldn't be a queue, it is a poor replacement for a state. (It
happens to be as it is, because it was copied from the gdbmi
debugger....). Its purpose is to ensure, that watches do not run, while
the target is running, or step/run is not done while evaluating a watch.
So basically if an "action" (that may consists of one or many commands
to the external exe) needs to wait for the correct debuggerstate, then
that somehow happens here. Not all actions need to wait, so they may
bypass that queue.....
To start with ignore the inner queue, and send your commands directly to
the external exe. Once you can do that, you can start thinking about
coordinating the bigger picture.
--
_______________________________________________
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
