[fpc-devel] I have created a openocd debugger-interface for lazarus, now some questions

[Michael Ring]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20130207/2865657f/attachment.html>