Lazarus
Using the Lazarus IDE => Debugger => Topic started by: halmariane on March 01, 2013, 05:48:26 pm
-
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
-
Debugging through SSH apparently is possible but IIRC there are some limitations. See e.g.
http://wiki.lazarus.freepascal.org/IDE_Window:_Debugger_Options
-
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.
-
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 (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
-
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.
-
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.
-
---------------------------
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.
-
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.
-
Have you tested if the latest GDB on your target support
set target-async on
Just got feedback from the people who tried on QNAP, and there it does have it.
-
Have you tested if the latest GDB on your target support
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.
-
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.
-
Have you tested if the latest GDB on your target support
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 (http://stackoverflow.com/questions/10607021/c-thread-not-stopping-in-gdb-async-mode-using-user-defined-or-python-command-s)
Regards
-
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.
-
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
-
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.
-
---
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.
Good news Martin.
For the moment thanks to your help at least i can run remotely the application and more,..... i can stop it by a breakpoint, inspect variables ...
One very important and missing detail is that if we need debug remotely other platforms then we need to compile the local gdb sources indicating the target platform. Remember that in this case i am debugging arm-linux hardware from x64-linux hardware, so there are needed to solve other issues that are nothing to see with Lazarus.
We need to debug some things as you told me. There is some strange warning that i can not understand, and ... there are confused debugger options for me that i think are undocumented like "append-gdb-to-openssh-opt", or "consoletty"..... really i think that i need understand almost all options.
For the moment if i want to work with remote debugging i need set to true "append-gdb-to-openssh-opt" but i don't know the reason.
I have to say also that this method is similar to Borland Remote Debugger. In Borland Remote Debugger we need start a remote debugging server and then configure the client options. Run option from the IDE and it takes the control of the program such as occurs in Delphi 7.
Thanks to remote debugging i have detected there is an issue regarding gtk2 unit that i would like to report later.
I will try more..
Regards
-
After a few testings i would like to post what i think that it's missing to remote debugger. I think that some has been published yet, i am not sure:
When the application is running.......
- Application can not be paused
- Application can not be stopped
- No more breakpoints can be added after running
- Getters of properties can not be debugged
I have to check why gdbserver stops when the application halts also.
-
After a few testings i would like to post what i think that it's missing to remote debugger. I think that some has been published yet, i am not sure:
When the application is running.......
- Application can not be paused
- Application can not be stopped
- No more breakpoints can be added after running
That is all caused by the same issue. And was attempted to be solved using the new target async.
run gdb on the target (or gdbserver, if you use that, and then connect to it). No need to load a project.
Enter:
set target-async on
show target-async
The 2nd command must say, that it is on.
Also: You are using the latest Lazarus? Either a snapshot of Lazarus 1.1 (Lazarus 1.0.7 will NOT do) or SVN/trunk. And also it must be revision 40412 or higher. Dated 26 February or later.
If so, then please supply a log as described here: http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#Log_info_for_debug_session
- Getters of properties can not be debugged
That is a known issue, and unfortunately not easy to fix. This applies to all debugging, not just remote. Please read the rest of the page, that I linked above.
-
Also: You are using the latest Lazarus? Either a snapshot of Lazarus 1.1 (Lazarus 1.0.7 will NOT do) or SVN/trunk. And also it must be revision 40412 or higher. Dated 26 February or later.
Martin, finally it works. Seems that it is in the very right way. Here are what i have needed in my case to remotely debug an ARM-Linux application from a X64-Linux system.
LOCAL SYSTEM (x64)
- FPC version 2.7.1
- Lazarus 1.1 SVN 40461
- Linux Mint Debian X64
- Manually include GDBMiServerDebbuger in the public "uses" clause of debugmanager.pas file located in lazarus/ide
- Build Lazarus IDE
- Config, make and make install GNU debugger sources to support ARM-Linux system debugging (CrossCompiled ARM debugger)
- Lazarus-> Menu-> Tools-> Options-> Debugger: Select GNU Remote Debugger (gdbserver), Fill the editbox with the path to croscompiled ARM-debugger, IP or Name of the remote system in the Debugger_Remote_HostName property
- Follow the instructions located in http://wiki.lazarus.freepascal.org/Remote_Debugging (http://wiki.lazarus.freepascal.org/Remote_Debugging) to configure SSH without password prompting
- Transfer the crosscompiled project to remote system.
REMOTE SYSTEM (ARM)
- Linux Raspbian Wheezy
- Execute shell command : gdbserver host:2345 name_of_executable_project. In case of GUI application it must be executed from a X11 terminal.
LOCAL SYSTEM (x64)
- Run command/option from the IDE.
- Enjoy
Very good job. Congratulations.
Thanks and best regards