Over the weekend I tried to see if it is possible to change from my current approach of using cgdb for debugging embedded projects back to lazarus.

So I took my old patches and for lazarus and based on the patches I wrote a new debugger unit for openocd.

So far so good, but I am having an issue in the early startup phase in

TGDBMIDebuggerCommandStartDebugging.DoExecute

After the breakpoint for main is set and -exec-continue is called (I tried both the async and not async version):

@@ -5007,15 +5030,20 @@

        // RUN
        DefaultTimeOut := 0;

- if not ExecuteCommand(Cmd, R, [cfTryAsync]) +// if not ExecuteCommand(Cmd, R, [cfTryAsync])
+ if not ExecuteCommand(Cmd, R)

the debugger comes back with the (gdb) prompt before the stop at the breakpoint.

This confuses StartDebugging, the next thing is tries is to remove the breakpint, this fails because the debugger thinks the process is still running.

I checked with gdb directly connected, there the output in non-async mode looks good:

(gdb) break main
Breakpoint 1 at 0x80001c4: main. (2 locations)
(gdb) continue
Continuing.
Note: automatically using hardware breakpoints for read-only addresses.

Breakpoint 1, main () at Nucleol053r8.pas:70

and in async mode also not bad:

(gdb) break main
Breakpoint 1 at 0x80001c4: main. (2 locations)
(gdb) cont &
Continuing.
Note: automatically using hardware breakpoints for read-only addresses. (gdb)
Breakpoint 1, main () at Nucleol053r8.pas:70

Here's the output of lazarus with debugging turned on:

> TCmdLineDebugger.SendCmdLn "-break-insert main"

<< TCmdLineDebugger.ReadLn
"^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="<MULTIPLE>",times="0",original-location="main"},{number="2.1",enabled="y",addr="0x080001c4",file="Nucleol053r8.pas",fullname="/Users/ring/devel/nucleo-l053r8/Nucleol053r8.pas",line="70",thread-groups=["i1"]},{number="2.2",enabled="y",addr="0x080001c5",at="<main+4294967295>",thread-groups=["i1"]}" << TCmdLineDebugger.ReadLn "(gdb) "

> TCmdLineDebugger.SendCmdLn "-exec-continue"

<< TCmdLineDebugger.ReadLn "~"Note: automatically using hardware breakpoints for read-only addresses.\n""
<< TCmdLineDebugger.ReadLn "^running"
<< TCmdLineDebugger.ReadLn "*running,thread-id="all"" << TCmdLineDebugger.ReadLn "(gdb) "

> TCmdLineDebugger.SendCmdLn "-break-delete 2"

<< TCmdLineDebugger.ReadLn "@"WARNING! The target is already running. All changes GDB did to registers will be discarded! Waiting for target to halt.\n""

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150510/8a1ddeef/attachment.html>

This is the GDBMIServerDebugger?

There is' a flag, in the debugger-properties, to allow/disallow async. I have to chack, but IIRC:
- in GDBMIDebugger it is not set, so the flag is always ignored. (and it may not be published, so not editable)
- In GDBMIServerDebugger it is set (and published)

Try to unset async in config.

the debugger comes back with the (gdb) prompt before the stop at the breakpoint.

That should be normal. "run" or "continue" (any run command) has 2 prompts in return.

1st prompt => acknowledges the command (the state changes to run) 2nd prompt => should be after state changed to stopped, ready for next command.

In async mode it is more tricky, because one prompt (IIRC the 2nd) may (sometimes) be missing.
It makes sense, as in async mode, gdb takes input while running.

those are none MI commands. They may behave different.

use "gdb -i mi" and then the gdbmi commands

odd...
Please add

       // RUN
       DefaultTimeOut := 0;
       if not ExecuteCommand(Cmd, R, [cfTryAsync])
       then begin
         SetDebuggerErrorState(Format(gdbmiCommandStartMainRunError,
[LineEnding]),
                               ErrorStateInfo);
         exit;
       end;
////ADD ////////////////////////<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
debugln(['After RUN ',dbgs(r.State)]);

----------------------------------------------------------

and log with

--debug-log=LOG_FILE
--debug-enable=DBG_CMD_ECHO,DBG_STATE,DBG_DATA_MONITORS,DBGMI_QUEUE_DEBUG,DBGMI_TYPE_INFO,DBG_VERBOSE,DBG_EVENTS,DBG_STATE_EVENT

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150510/6842066d/attachment.html>