Remote Debugging [SOLVED, It works]

[halmariane]

Hi every body:

I'm new in the forum, so i would like to greet all.

Ok, searching in the forum it is the question that is not still very clear. Assuming that we have the latest version of Lazarus:

1.- Can lazarus debug one remote application or no?
2.- Anybody knows how is the way (IDE configuration) to debug one application located in other computer?

I don't know if i am navigating alone in this big sea. Such as i see it the remote debugging is as important as local debugging, and in the Lazarus case i think that more than others, because Lazarus compiles to other platforms, and the application not always resides in the local computer. In my case very few times.

Regards to all

[BigChimp]

Debugging through SSH apparently is possible but IIRC there are some limitations. See e.g.
http://wiki.lazarus.freepascal.org/IDE_Window:_Debugger_Options

[Martin_fr]

http://wiki.lazarus.freepascal.org/Remote_Debugging

There is some work in progress in the very latest Lazarus 1.1 from trunk.
It also depends on the remote target in use.

There is a new class for debugging using GdbServer.

But it needs to be added by hand, and the IDE rebuild.
- Add GDBMIServerDebugger
- to the "uses" clause of "DebugManager" (in  folder ide)

There is a thread on this forum, that explains how to use it.

It has the same limits, UNLESS your gdb (and gdb server) does support async (target-async) mode.
gdb does NOT specify which versions do. It depends on your platform / OS on the target.

[halmariane]

Debugging through SSH apparently is possible but IIRC there are some limitations. See e.g.
http://wiki.lazarus.freepascal.org/IDE_Window:_Debugger_Options

Thank you BigChimp.

Yes, i have watched this post and followed the instructions. After i have visited http://forum.lazarus.freepascal.org/index.php/topic,19014.msg107930.html#msg107930 without good results. For that reason i say that there must be a sequence to configure a remote debugging. no?. One tutorial or .... do you understand me?

Regards

[halmariane]

http://wiki.lazarus.freepascal.org/Remote_Debugging

There is some work in progress in the very latest Lazarus 1.1 from trunk.
It also depends on the remote target in use.

There is a new class for debugging using GdbServer.

But it needs to be added by hand, and the IDE rebuild.
- Add GDBMIServerDebugger
- to the "uses" clause of "DebugManager" (in  folder ide)

There is a thread on this forum, that explains how to use it.

It has the same limits, UNLESS your gdb (and gdb server) does support async (target-async) mode.
gdb does NOT specify which versions do. It depends on your platform / OS on the target.

Thank you Martin

I will try it other time.

I forgot comment that the target platform is ARM. I can crosscompile applications to that platforms with Lazarus and i need now debug them.

Thanks, i will post the results.

[Martin_fr]

If you speak german, there are 2 threads on the german forum:
http://www.lazarusforum.de/viewtopic.php?f=4&t=6645
http://www.lazarusforum.de/viewtopic.php?f=9&t=6664

According to which, at least older gdb on the specific arm target of that thread (QNAP) does not have target-async. Tests with the latest version are still ongoing. Also tests of gdb-server may still be lacking, and on some platforms only gdbserver, but not gdb has the feature.

----------------------------
As far as I am aware, there was very little interest in remote debug, until maybe 3 or 4 month ago.

In terms of development in the IDE: gdb-over-ssh is *very* old. And there was no development for it going on at all.
The first remote-debug development in years was by marius.maximus (as in the link you posted: http://forum.lazarus.freepascal.org/index.php/topic,19014.0.html ).

The only other, is the initial support for target async (which was implemented as a result of the above work).
It is not finished yet. It needs a lot of testing. And it needs safety checks, if GDB does not support the feature.

This is why the gdb server is not yet added by default. gdb-over-ssh was added a long time ago. Without target async, I would consider it as "not working". There is no point to add a 2nd flawed remote debug.
It will be added, once the above points have been cleared (no time plan/schedule yet)

---------------------------
Without target async support in GDB there is currently no solution.
Someone would have to write a small daemon to run on the remote, and send the signal (SigINT) to the debugged app. It would need to be controlled by the IDE over the network).

As far as I know, no-one is working on such a solution.
And: I do not plan to work on such a daemon at all (I will at some time continue with the target-async support).

This means, if such a daemon is wanted, someone has to contribute it.

[halmariane]

---------------------------
Without target async support in GDB there is currently no solution.
Someone would have to write a small daemon to run on the remote, and send the signal (SigINT) to the debugged app. It would need to be controlled by the IDE over the network).

As far as I know, no-one is working on such a solution.
And: I do not plan to work on such a daemon at all (I will at some time continue with the target-async support).

This means, if such a daemon is wanted, someone has to contribute it.

Martin

No, i don't speak German but Spanish.

And...... speaking about contributions to remote debugging....

do you know what are the requirements for this Daemon?. As you told me  "...It would need to be controlled by the IDE ....". So I understand that there are some especifications of the IDE or it has to be modified according to the protocol with the remote daemon.

[Martin_fr]

Look at procedure TGDBMIDebugger.InterruptTarget;
in  debugger\gdbmidebugger.pp  line 7796

1) When is this needed:
- This is *NOT* needed, to run an app in the debugger, and stop at a breakpoint, that existed (that was set *before* starting the debugger.
- This IS NEEDED to use the  "Pause" button.
- This IS NEEDED to set/remove breakpoints *while* the debugged app is running
  because to change breakpoints the debugged app must be paused temporarily

2) It needs the PID
at the end of nested
  function RunToMain(EntryPoint: String): integer;
in
  function TGDBMIDebuggerCommandStartDebugging.DoExecute: Boolean;

However that should work already for over-ssh (maybe not for gdbserver, to be tested)

3) What it does: It sends a signal (bit special on Windows) to the app
GDB catches this, and pauses the app.

4) You can override it in a sub-class (register a new debugger, based on the ssh version)

for config look at TGDBMIDebuggerPropertiesBase

5)
You may need to start/stop/initialize the daemon, and set up communication.
You have to find the places for that.

[Martin_fr]

Have you tested if the latest GDB on your target support

Code: [Select]

  set target-async on

Just got feedback from the people who tried on QNAP, and there it does have it.

[halmariane]

Have you tested if the latest GDB on your target support

Code: [Select]

  set target-async on

Just got feedback from the people who tried on QNAP, and there it does have it.

Hi Martín

The target system for the moment in this project is linux raspbian wheezy 2013-02-09. The project is compiled from Linux64 to ARM.

I will check support for this option that you say and I will post results.

Thanks.

[halmariane]

Threre is other interest in remote debugging and it's because the scrolling of TDBGrid component in ARM system causes application crash without any apparent reason.

[halmariane]

Have you tested if the latest GDB on your target support

Code: [Select]

  set target-async on

Just got feedback from the people who tried on QNAP, and there it does have it.

Martin

GDB version of the target ARM is 7.4.1-debian.

I checked manually the debugger running the application and to apply the command and seems to work. The application can be interrupted manually without problem. I can confirm also that something is wrong in TDBGrid crosscompiled for ARM because the scroll crash the application.

But i have not sure at all because of this link http://stackoverflow.com/questions/10607021/c-thread-not-stopping-in-gdb-async-mode-using-user-defined-or-python-command-s

Regards

[Martin_fr]

Well if target async works

That is you can run with "r &" and then type "interrupt" to pause the app, then you should be able to remote debug.

Either using the over-ssh, or by adding the GDBMIServerDebugger as I wrote in an earlier post.

It may still have bugs, but they can be fixed, if you report them here.

[halmariane]

Ok, i am a little bit confused still.

I suppose that the Daemon is only for platforms that does not support target-async. This seems that is not my case.

Either using the over-ssh, or by adding the GDBMIServerDebugger as I wrote in an earlier post.

It may still have bugs, but they can be fixed, if you report them here.

So by your words understand that i have two options:

1.- Using the debug over ssh integrated in Lazarus
2.- Using the GDBMIServerDebugger unit.

Am i in the right way??, and in this case ... which is recomended ??.  I am in disposition to do all the testings needed to debug the application remotely.

Regards

[Martin_fr]

I suppose that the Daemon is only for platforms that does not support target-async. This seems that is not my case.

Yes.

Either using the over-ssh, or by adding the GDBMIServerDebugger as I wrote in an earlier post.

It may still have bugs, but they can be fixed, if you report them here.

So by your words understand that i have two options:

1.- Using the debug over ssh integrated in Lazarus
2.- Using the GDBMIServerDebugger unit.

Am i in the right way??, and in this case ... which is recomended ??.  I am in disposition to do all the testings needed to debug the application remotely.

If you add the GDBMIServerDebugger , the way I described earlier in this topic, then it will be like the over-ssh. You can go to the Lazarus options, and it will be in the list of debuggers.

There is not much difference between them. But I would use gdb-server.

---
It will eventually be added and be available by default.

But I made the latest changes (async) in a bit of a rush. I had no time to test them, and I have not added any error handling yet.

Once that is done, this will be the added.