Hello together!

I have a arm-wince project (using LCL) where I have a stacktrace and I'd like to resolve the symbol information. As I'm not cross debugging I'm using an offline (post mortem) process for which I compile my application with debug information, but also -Xg to get a seperate symbol file which I can use with GDB. Now the problem is that since the last time I needed these symbols my application seems to have gotten big enough that the debug information triggers the "Executable image size too big for arm-wince target" error.

I'm currently using 2.6.0 on i386-win32. If compiled for i386-win32 the application's size is 3.7 MB while the debug information size is 42 MB (the application size for arm-wince is 4.3 MB).

I've looked a bit inside the compiler and shouldn't it be possible and worthwhile to not raise this error if one is cross compiling and currently the debug file is generated (the corresponding location is - in trunk - ogbase.TExeOutput.SetCurMemPos)? Or maybe define a list of targets where it should be allowed when cross compiling.

Regards,
Sven

05.02.2013 19:32, Sven Barth пишет:

An interesting issue. On ELF targets all debug sections are placed at zero address, so such error can arise only if size of a single section exceeds limit, but on COFF targets like arm-wince debug sections consume address space (although they are not loaded). Maybe we should simply ignore the address limit for debug sections, or maybe only when generating external debug file.

Regards,
Sergei

That's the idea. You are currently more experienced regarding the output generator, so if you can find the time to change this...

I've solved the problem for now by not compiling the LCL with debug information, but even then my debug information is already ~25 MB and the size limit on WinCE is around 33 MB. (and the error I experienced was in FPC's RTL and was fixed by me in r23574 :) )

Regards,
Sven

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

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.

...

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 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.

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

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

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

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

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.

...

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 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.

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

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

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

Yes, OpenOCD implements a gdbserver so debugging is done via gdb.

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 will join the german lazarus forum, see you there.....

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

Michael Ring wrote

I will join the german lazarus forum, see you there.....

http://www.lazarusforum.de/viewtopic.php?f=9&t=6664&start=15

-Michael

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

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;

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.

see above

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

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

In the last weeks I spent most of the time to actually use lazarus + the debugger-interface, I have identified some rough edges that I need to work arround but basically the code works when you do the steps in the right order.

How comfortable are you to rebuild lazarus-trunk? If you are fine with this I can send you my patches via mail & some instructions on how debugging works best.

Michael

i build from the trunk / svn alot so its good.

pls email me the patches.

Kind Regards

Justin