Home » Language IDEs » C / C++ IDE (CDT) » Eclipse CDT: Debugging locally on the target by the means of ssh+local gdb
| Eclipse CDT: Debugging locally on the target by the means of ssh+local gdb [message #699087] |
Wed, 20 July 2011 19:40  |
 Jusctsch 
Messages: 22
Registered: July 2011 |
Junior Member |
|
|
Hello all,
I have a setup which would work great for gdbserver.
I would like to keep my sources local, my symbol file local. The target is currently running a stripped binary of my intended-to-debug program.
However, the platform doesn't currently have a thread-conscious gdbserver (FreeBSD), so we can throw out that idea. Also, there is no UI on the target system and I would like to debug it via a UI such as Eclipse.
So, it would seem that the best solution would be to attempt a gdb session over ssh, and pump that into the Eclipse UI. If only this was simple; there are at least 3 methods AFAIK in which I could do this, being the following:
(in the debug configuration tab)
C/C++ Attach to Application
GDB Hardware Debugger(Standard GDB Hardware Debugging Launcher)
GDB Hardware Debugger(DSF!)
I have had varying levels of success running gdb through ssh through these, but
I have not had enough success to say that one of the debugging types is better than another for gdb ssh.
Which of the above methods is the 'de facto' choice for remote debugging on FreeBSD?
Thanks-!
htt#p://ww#w.slideshare.net/kepler2/eclipse-con-talk2273
|
|
| | |
| Re: Eclipse CDT: Debugging locally on the target by the means of ssh+local gdb [message #699431 is a reply to message #699093] |
Thu, 21 July 2011 14:32  |
Jusctsch
Messages: 22
Registered: July 2011 |
Junior Member |
|
|
Hello Mark,
The matrix of combinations for setting up a debugging session is so huge, that it's easy to trip on something. Clarification on the matrix goes a long way
Question:
How does eclipse seem to format the gdb/run commands?
Assumption:
When you start a session of gdb it is common to do the following:
gdb $NameOfProgramBinary
run $args
Now to put that in Eclipse terms, in the debug config popup there is a Main, Arguments, Environment, Debugger, Source, Common tab for the DSF C/C++ Application debugging mode. The different tabs have different fields, and it using those fields seems like they format the above 'gdb run' commands as follows:
$GDB debugger $C/C++ Application
run $Program arguments
In the case above, in which we create an *edit* 'remote' (via ssh) debugging instance on the local machine, the fields are formatted as such
$GDB debugger = ssh localhost gdb
$C/C++ Application = whiskers
$ Program arguments = /usr 2 foo
With which Eclipse says:
ssh localhost gdb whiskers
run /usr 2 foo
Is this an accurate statement?
From what I've seen, the basic case works fairly well, but we run into trouble when we need to advanced things, such as attach to existing processes, and communicate with versions of gdb compiled for different operating systems than the host.
*edit*
My desired solution is to debug a very large application over ssh-gdb on FreeBSD, and be able to attach to it if needed as well. Right now I run into a lot of errors/hangs due to Eclipse not being able to handle certain messages. Also, I see the issue in this problem:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=225805
My two cents:
It would be nice to be aware of what Eclipse is actually doing under the hood when opening a debugging session. It tries to make things easy by issuing the 'gdb' commands itself, but we can run into issues where the gdb session responds with unexpected (to Eclipse) but recoverable replies that will 'hose' us before we get a chance to interact with the command line. These unexpected replies will either crash the debugger (because Eclipse sends irrelevant garbage because its expecting a different reply), or hang the session (because the session will never work, but Eclipse doesn't understand the error response).
Thanks again for the quick response
[Updated on: Thu, 21 July 2011 17:04] Report message to a moderator |
|
| | | |
| Re: Eclipse CDT: Debugging locally on the target by the means of ssh+local gdb [message #702623 is a reply to message #701942] |
Tue, 26 July 2011 15:36 |
Jusctsch
Messages: 22
Registered: July 2011 |
Junior Member |
|
|
Marc,
I had interesting 'success' with my attempt yesterday. Using the trace, I was able to see exactly where it was getting hung up- if it was a communication issue or a timeout and where it occurred. I had success, but first I'll explain my setup.
Prerequisites:
*Target machine is currently running the application, therefore we must 'attach'
*Source would be desirable to be kept on host machine
*No gdbserver on target
*Target machine is FreeBSD
Fields in Eclipse:
C/C++ Attach to Application:
Main:
C/C++ Application:
unstripped binary
Project:
myrunningprocess_project
Other:
Disable auto build = checked
Debugger:
gdb (NOT gdbserver)
Debugger Options Main:
GDB debugger:
ssh -t -t root@172.21.44.11 /mnt/gdb/gdb72_real -p 2018
GDB command file
.gdbinit
Source:
Default
Result:
Connecting to the target in this manner opened up a gui list of running processes on the HOST system. Choosing the PID of a running process on the host system which is not present on the target system leads to a failure. Choosing the PID of the running application on the target system lead to a failure, as there was no pid of that value running on the host system (in the nice gui list of running processes on the host).
To fix this, I wrote a program that made a bunch of persistent dummy programs on the host that would produce the pid of the running process on the target system. I then chose that pid in the 'gui list' of host processes that appears on connecting.
There were a few other 'hacks' that it seemed like I had to do to make this work however,
*I had to make a directory on the target containing the sources files mirroring the location of the source files included on the host (I left it empty)
*I had to make a directory on the target containing the unstripped binary to load symbols, again mirroring the location on the host
Using all of this, I could get a debugging session attached to the process running on the target system:
ps -x
2286 ?? TXs 0:04.95 /tmp/myrunningprocess
1345 0 Is+ 0:00.01 csh -c /mnt/gdb/gdb72_real -p 2018 --interpreter mi2
1374 0 S+ 0:01.12 /mnt/gdb/gdb72_real -p 2018 --interpreter mi2 --nx
Now the issue is that I have a nice warning saying "No source available for ____ "
Questions:
1. Does choosing gdb instead of gdbserver assume that the connection will be local?
2. Why does a gui list of running processes on the host open up if I am connected to the target?
3. What changes should be done to allow this ssh-gdb debugging functionality to be easily done in future releases of Eclipse?
4. Is there a way to keep the source on the host, then 'move it over' when needed on the target (automatically by eclipse), or should I just nfs mount the source locally to the target?
5. Is there a module in Eclipse that can do the above, without the hacks? I have had some success with the Hardware Debugger- but I don't think it has undergone enough usage to flesh out issues.
Thanks again Marc, you have been extremely helpful so far.
Hopefully we can iron out these details so people who desire to do this in the future have a place to look at.
**Edit**
It looks like the -p argument on the 'gdb call' was inconsequential. Notice that the argument following the -p doesn't match the attached pid shown under the ps -x. This is because of the gui list that was thrown to me by eclipse had the relevant pid and I chose that one...
I can supply Screenshots if needed
**2nd Edit**
Ignore this method, use the GDBHardware debugger instead
http://www.eclipse.org/forums/index.php/m/704296/#msg_704296
[Updated on: Tue, 02 August 2011 14:11] Report message to a moderator |
|
| |
Goto Forum:
Current Time: Fri Apr 26 03:54:18 GMT 2024
Powered by FUDForum. Page generated in 0.03956 seconds |
] 
Search
Help
Register
Login
Home
