Am 07.02.13 16:04, schrieb Martin:
On 07/02/2013 07:14, Michael Ring wrote:
One more thing, do you know why ExecuteCommand is defined as
protected and not public in GDBMIDebugger? I need to send some extra
commands to GDB to make the remote connection, using ExecuteCommand
is an elegant way to do this. But the method is invisible in my class
because it is protected. Can the ExecuteCommand methods be made
public or is this a no-go?
They (the ones in GDBMIDebugger, not the ones in
TGDBMIDebuggerCommand) should be deprecated and removed.
All commands must go via TGDBMIDebuggerCommand. This is because GDB
may need to be set into the correct state (select thread/stack).
The ones in TGDBMIDebugger are left overs from long ago. They do work,
because they do actually encapsulate the command in a
TGDBMIDebuggerCommand
I have plans to change this and introduce a new "inner" queue, that
will automatically da the necessary thread/stack selection.
Then also the TGDBMIDebuggerCommand should be changed, so they do not
expect a result from a gdb command, but assign an event, and get
called back. So ProcessMessages will no longer be needed.
But that is still some time to go.
---
As for you, You should be able to inherit from TGDBMIDebuggerCommand?
Also I do not understand why you do not see a protected class. You do
inherit from TGDBMIDebugger? And if you have helper objects, then you
can create a public wrapper in your main class.
The problem was sitting in front of the screen.... During some tests I
did not subclass TGDBMIDebugger but created a new instance. That's I
guess why I could not see ExecuteCommand.
But now I have cleaned up my code-mess, there are currently only two
small code changes left in GDBMIDebugger and Debugger, one more will
come for the breakpoint handling.
Without you great comments I would have never made it that far, thank
you again!
Index: debugger/debugger.pp
===================================================================
--- debugger/debugger.pp (revision 40204)
+++ debugger/debugger.pp (working copy)
@@ -3304,6 +3304,7 @@
const
OLD_GDB_DBG_NAME = 'GNU debugger (gdb)';
OLD_SSH_DBG_NAME = 'GNU debugger through SSH (gdb)';
+ OLD_REMOTE_DBG_NAME = 'GNU debugger through OpenOCD (gdb)';
var
s: String;
begin
@@ -3314,6 +3315,7 @@
s := ConfigStore.GetValue('Type', '');
if s = OLD_GDB_DBG_NAME then FDebuggerClass:='TGDBMIDEBUGGER';
if s = OLD_SSH_DBG_NAME then FDebuggerClass:='TSSHGDBMIDEBUGGER';
+ if s = OLD_REMOTE_DBG_NAME then
FDebuggerClass:='TOPENOCDGDBMIDEBUGGER';
end;
ConfigStore.AppendBasePath('WatchesDlg/');
try
Index: debugger/gdbmidebugger.pp
===================================================================
--- debugger/gdbmidebugger.pp (revision 40204)
+++ debugger/gdbmidebugger.pp (working copy)
@@ -4502,8 +4502,12 @@
s := GetPart(['Thread '], [' '], R.Values, True);
Result := StrToIntDef(s, 0);
if Result <> 0 then exit;
+
+ // returned by openocd server
+ s := GetPart(['* '], ['Remote target'], R.Values, True);
+ Result := StrToIntDef(trim(s), 0);
+ if Result <> 0 then exit;
end;
-
// no PID found
SetDebuggerErrorState(Format(gdbmiCommandStartMainRunNoPIDError,
[LineEnding]));
end;
Which GDB version is your prefered version for debugging FreePascal?
I run the testcase for gdb 6.3 to 7.5. So the IDE can communicate with
all of those.
On Mac, apple provides a modified 6.3.5
On Windows (at least 32 bit) I recommend 7.2. 7.3 up has some
regressions
http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#Bugs_in_GDB
Win64 I am not sure
On Linux any 7.x should be fine
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
