Re: [fpc-devel] I have created a openocd debugger-interface forlazarus, now some questions
how close are we to adding openocd to the debugging in lazarus ?
is there a simple configuration file to change or patch to use ?
i want to be try openocd for debugging.
King Regards
Justin Smyth
From: Martin
Sent: Friday, February 8, 2013 11:09 AM
To: FPC developers' list
Subject: Re: [fpc-devel] I have created a openocd debugger-interface
forlazarus, now some questions
On 07/02/2013 23:51, Michael Ring wrote:
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)';
You should not need this.
Older versions of the IDE used those strings in the XML. But now the IDE uses
the classname.
The 2 existing old names are kept so old config can be read.
There is no old config for your class.
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';
see above
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;
I'd rather factor all of the "get PID" code into a virtual method. (on the
class TGDBMIDebuggerCommandStartDebugging)
Actually that might be the entire "RunToMain"
Then you can override it, and add there.
That means you have to subclass TGDBMIDebuggerCommandStartDebugging. See the
GDBMIServerDebugger haw to do that
___
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
Re: [fpc-devel] [Solved] Strange behaviour with Synapse
On 03/17/2013 02:19 PM, Ludo Brands wrote: Get your GUI stuff out of the download thread Easy to do using TThread.Queue() -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Strange behaviour with Synapse
On 03/17/2013 09:05 AM, Ludo Brands wrote: you create a string for the GUI, synchronize to update the screen, call Application.Processmessages to make sure the GUI gets updated. I would suggest to do those GUI updates by QueueAsyncCall() or TThread.Queue() (TThread.Queue uses the same syntax as Synchronize and thus is rather easy to use in your case (beware of string references, though), but it might be present only in the svn version of fpc as it is rather new (because it has been existing but not documented in Delphi until rather recently. ) TThread.Queue works like TThread.Synchronize, but does not stall the thread until the mainthread has done the requested action. Thus, if no result is to be reported back or mutual access problems are lurking, it is is a lot better than Synchronize: The thread keeps running and no performance-eating ProcessMessages is necessary. QueueAsyncCall does the same, is more versatile but uses different Syntax and is not available in Delphi. ( PostMessage / procedure ... message does the same, is available and documented in Delphi, but uses very ugly fake-Windows syntax, even if used in Linux. ) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Strange behaviour with Synapse
On 03/16/2013 07:55 PM, Ludo Brands wrote:
Well it can always cause a problem because FHttp.Clear clears the
Header and Document. If that happens while you are executing the HEAD,
strange results can happen.
In fact a a very recent project my problem was that I misread the
Synapse Docu and assumed that with a new HTTPMethod() call the send
buffer ("document") would be clear. But on the contrary the send buffer
is filled with the latest received document. This in fact leads to
programs that mostly work but are due to very peculiar problems, as the
target HTTPserver might overrun and timeout ow whatever when bombed
with huge request frames.
I don't think this is very hand, but I asked the software creators and
it's a feature not a bug.
Thus before using HTTPMethod() of an instance of THTTPSend a second
time, you to always need to clear the document buffer before.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc 2.6.2 - heaptrc and dwarf will crash
On 03/17/2013 08:53 PM, Martin wrote: > It seems that in FPC 2.6.2 the dwarf reading code in LnfoDwrf is broken. > It always gives a run-error 131 > Reported and cause identified more than a year ago: http://bugs.freepascal.org/view.php?id=20296 Ludo ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
