[Lazarus] mEDBG Debugger [[was: Re: Switching debugger based on Project settings for embedded targets]]

[Martin Frb]

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.