TAsyncProcess
is actually only used by LLDB (the reasons for that a different) - gdb is accessed by normal TProcess. components\lazdebuggergdbmi\cmdlinedebugger.pp
A normal TProcess means that (unless you use threads) you need Application.ProcessMessages. And that can get messy...
components\lazdebuggers\cmdlinedebuggerbase\debugprocess.pas is the answer to that. TAsyncProcess had some other issues (don't recall), so I wrote my own.
I never had "partial lines" issue. But what should be done with respect to reading lines
That should avoid unwanted line breaks, for most situations.
And find PseudoTerminal and use it, and
That way the programs output, will not interfere with the gdb responses.
Both cmdlinedebugger and debugprocess should be fine for being used as a baseclass.
debugprocess has not yet reached its potential. Lets dive in.
Current GDBMI has a "command object" for everything. For example for evaluating a watch, or locals, or stack.
And while the object is running it has control. It can set the stackframe and thread, and then issue the commands it needs.
Debugprocess, actually DebugInstructions, should change that.
DebugInstructions receives Instruction objects, only containing one gdb (at current lldb) command at a time. But the object has fields for desired thread and frame, and DebugInstructions then sets the frame as desired.
This should in future all DebugInstructions to re-order the received instructions, and issue less stack changes. (improve speed).
But it is a work in process.
For that reason DebugInstructions is an event emitter. The Instruction object does not wait for the result. It gets called again, when the result is available. And that means no ProcessMessages.
didn't get full answers from GDB
should not happen, except if gdb crashes (you need to first check the errors while reading from the process), or if app-output is mixed in.
You may want to look at TGDBMIDebuggerInstruction.ProcessInputFromGdb
For arrays, the D ones work in GDB
For arrays with static size, that should always be ok, arrays with dynamic size will probably depend on the dwarf version. dwarf 2 simply had no provisions to encode the length. dwarf3 has (and fpc uses that, and gdb knows how to read it / and so does fpDebug)
Under windows that's a mess
I guess D-compilers on win do not use dwarf, but PDB. So you need a diff debugger.