Re: [fpc-devel] I have created a openocd debugger-interface for lazarus, now some questions
As we now are in a dedicated thread: - I suppose this should be discussed in the Lazarus mailing List. - Does openocd not use gdb ? . - If yes, support maybe should be provided by the GDBMIServerDebugger unit (or similar). We are discussing a similar issue in the German Lazarus Forum right now to allow for remote debugging headless ARM devices via TCP/IP. . - If no, maybe a different unit similar to GDBMIServerDebugger needs to be created. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] I have created a openocd debugger-interface for lazarus, now some questions
On 02/07/2013 12:11 PM, Michael Ring wrote: I did not want to break existing code so I created a new class based on TGDBMIServerDebugger, this has been done before for the ssh based debugging so I followed this road. I just checked how this works: The nioce Lazarus team implemented the Interface to the debugger in a way that you just can add another unit and then in the Lazarus options you can select the new debugger from a list including all debugger interface Units that have been used in ide\debugmanager.pas. Great stuff. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] I have created a openocd debugger-interface for lazarus, now some questions
On 02/07/2013 12:11 PM, Michael Ring wrote: I will join the german lazarus forum, see you there. http://www.lazarusforum.de/viewtopic.php?f=9t=6664start=15 -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] I have created a openocd debugger-interface for lazarus, now some questions
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. 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
Re: [fpc-devel] I have created a openocd debugger-interface for lazarus, 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
Re: [fpc-devel] I have created a openocd debugger-interface for lazarus, now some questions
Hi Martin, Thank you for your detailed answers and for pointing me to the testcases. I am having a look at the breakpoint code and will see what I can do so that debugging works with only a limited number of available breakpoints. 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? Which GDB version is your prefered version for debugging FreePascal? Thank you again, Michael On 05/02/2013 22:14, Michael Ring wrote: I have integrated openocd debugger class as a child of the gdbmi debugger classes, basic code upload debugging now works for me in lazarus, still has some rough edges, this is why I am seeking for support by the arm-embedded hackers here in fpc-devel. ... single stepping works, I seem to have trouble with creating breakpoints, I run out of them very fast, for example lazarus shows me 3 breakpoints, openocd complains that it is already at breakpoint #11, is this a well known problem or do I need to investigate deeper into this? Hi. I don't know much about openocd. But I do know the debugger stuff in Lazarus. Since you say it is based on the gdbmi classes: There are a number of breakpoints inserted by GDBMI at startup. First GDBMI runs the exe to the main-entry-point. It does that in order to then set other breakpoints and do other initialization (which on some platform depending on gdb and god knows what, can only succeed *after* the initial run). a) up to 4 breakpoints (each by name AND address) to stop at main entry point. find function: function RunToMain(EntryPoint: String): integer; b) 3 breakpoints in fpc, to catch exception, run-error and some other c) run the program. So that gives the breakpoints you see. This can be moved to a virtual method, if a suitable patch is supplied. Also, visibility of variables is not that good, I can see simple variables in my procedures but more complex variables are usually invisible. Is this a known problem or is there just some magic I need to apply in the startup of gdb? Complex variables are read via a great many conditions. Each GDB reports slightly different, and needs slightly different corrections e.g a class may have to be deferred (Foo^.FField), or even first typecasted (to the type already detected by GDB via ptype). That is mostly done in GDBTypeInfo I have run various commands, for various datatypes against a dozen different GDB (and I keep doing for new releases). Some examples are in debugger\test\gdb responses\ For in IDE testing define (be warned, you can screw the debug session. Do NOT run or step). DBG_WITH_DEBUGGER_DEBUG // adds commandline to debug output window DBG_WITH_GDB_WATCHES // Allows watches or eval-window gdb_command Another issue is that I cannot do the loading of my binary from within gdb, at the moment I still need to do direct telnet communication with openocd. Not sure if it helps, there also is a class that started work on gdbserver / it is in SVN Which library should I use for doing the telnet session? I read on the freepascal wiki that fcl-net is a little outdated, so which library should I use, I do not want to introduce additional dependencies to the lazarus build by including synapse or indy. If your exe is remote, you need to disable the pause functionality (which is also called if you change breakpoints while running (not paused). Because it sends a signal to a local process ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] I have created a openocd debugger-interface for lazarus, now some questions
In the last days I have had a nice fight with lazarus-trunk, but it seems I succeeded in the end ;-) I have integrated openocd debugger class as a child of the gdbmi debugger classes, basic code upload debugging now works for me in lazarus, still has some rough edges, this is why I am seeking for support by the arm-embedded hackers here in fpc-devel. Do you guys have some best practices, magic startup scripts, etc... that make debugging of embedded targets more successful? I would like to include those tricks in the debugger class. single stepping works, I seem to have trouble with creating breakpoints, I run out of them very fast, for example lazarus shows me 3 breakpoints, openocd complains that it is already at breakpoint #11, is this a well known problem or do I need to investigate deeper into this? Also, visibility of variables is not that good, I can see simple variables in my procedures but more complex variables are usually invisible. Is this a known problem or is there just some magic I need to apply in the startup of gdb? Another issue is that I cannot do the loading of my binary from within gdb, at the moment I still need to do direct telnet communication with openocd. Which library should I use for doing the telnet session? I read on the freepascal wiki that fcl-net is a little outdated, so which library should I use, I do not want to introduce additional dependencies to the lazarus build by including synapse or indy. Lots of questions, I know, but perhaps some of you guru's can help ;-) btw, If someone whats to give the lazarus version a try, I have binaries for MacOS i386 and will have binaries for Windows i386 or Linux soon (in case anybody is interested) I still need to cleanup my changes, there are now way too much additional debug messages in the sourcecode of the gdbmi classes. Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] I have created a openocd debugger-interface for lazarus, now some questions
On 05/02/2013 22:14, Michael Ring wrote: I have integrated openocd debugger class as a child of the gdbmi debugger classes, basic code upload debugging now works for me in lazarus, still has some rough edges, this is why I am seeking for support by the arm-embedded hackers here in fpc-devel. ... single stepping works, I seem to have trouble with creating breakpoints, I run out of them very fast, for example lazarus shows me 3 breakpoints, openocd complains that it is already at breakpoint #11, is this a well known problem or do I need to investigate deeper into this? Hi. I don't know much about openocd. But I do know the debugger stuff in Lazarus. Since you say it is based on the gdbmi classes: There are a number of breakpoints inserted by GDBMI at startup. First GDBMI runs the exe to the main-entry-point. It does that in order to then set other breakpoints and do other initialization (which on some platform depending on gdb and god knows what, can only succeed *after* the initial run). a) up to 4 breakpoints (each by name AND address) to stop at main entry point. find function: function RunToMain(EntryPoint: String): integer; b) 3 breakpoints in fpc, to catch exception, run-error and some other c) run the program. So that gives the breakpoints you see. This can be moved to a virtual method, if a suitable patch is supplied. Also, visibility of variables is not that good, I can see simple variables in my procedures but more complex variables are usually invisible. Is this a known problem or is there just some magic I need to apply in the startup of gdb? Complex variables are read via a great many conditions. Each GDB reports slightly different, and needs slightly different corrections e.g a class may have to be deferred (Foo^.FField), or even first typecasted (to the type already detected by GDB via ptype). That is mostly done in GDBTypeInfo I have run various commands, for various datatypes against a dozen different GDB (and I keep doing for new releases). Some examples are in debugger\test\gdb responses\ For in IDE testing define (be warned, you can screw the debug session. Do NOT run or step). DBG_WITH_DEBUGGER_DEBUG // adds commandline to debug output window DBG_WITH_GDB_WATCHES // Allows watches or eval-window gdb_command Another issue is that I cannot do the loading of my binary from within gdb, at the moment I still need to do direct telnet communication with openocd. Not sure if it helps, there also is a class that started work on gdbserver / it is in SVN Which library should I use for doing the telnet session? I read on the freepascal wiki that fcl-net is a little outdated, so which library should I use, I do not want to introduce additional dependencies to the lazarus build by including synapse or indy. If your exe is remote, you need to disable the pause functionality (which is also called if you change breakpoints while running (not paused). Because it sends a signal to a local process ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] I have created a openocd debugger-interface for lazarus, now some questions
On 05.02.2013 23:14, Michael Ring wrote: In the last days I have had a nice fight with lazarus-trunk, but it seems I succeeded in the end ;-) I have integrated openocd debugger class as a child of the gdbmi debugger classes, basic code upload debugging now works for me in lazarus, still has some rough edges, this is why I am seeking for support by the arm-embedded hackers here in fpc-devel. Please don't answer to existing mail threads with a new question as it is less likely that your question will be seen this way. And this also corrupts the thread view of the mailing list archives. Just write a mail directly to the list's address without answering to another mail if you want to start a new topic. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
