LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > Programming
User Name
Password
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices

Reply
 
LinkBack Search this Thread
Old 01-15-2014, 05:25 PM   #1
john_erlandsson
Member
 
Registered: Jul 2009
Location: Sweden
Distribution: Fedora
Posts: 65

Rep: Reputation: 0
Remote debugging problems [SOLVED]


Hi guys!

I am trying to remote debug applications on a server in my local network.
Server:
Code:
#uname -a 
Linux broatyctl.localdomain 3.6.11.2-rt33.39.el6rt.x86_64 #1 SMP PREEMPT RT Thu Jul 4 06:46:48 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux
Workstation:
Code:
#uname -a
Linux workstation.localdomain 3.12.7-300.fc20.x86_64 #1 SMP Fri Jan 10 15:35:31 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
I compile a "Hello World" app on the workstation and it runs without errors on both workstation and server.

Code:
#gdbserver localhost:2345 CrossTest
and
Code:
#gdb CrossTest
(gdb)target extended-remote localhost:2345
(gdb)run
works on both the workstation and the server.

But when I run gdbserver on the server and gdb on the workstation I get:
Code:
Reading symbols from /home/john/dev/broaty/CrossTest/Debug/CrossTest...done.
(gdb) target extended-remote 192.168.1.105:2345
Remote debugging using 192.168.1.105:2345
Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from /usr/lib/debug/usr/lib64/ld-2.18.so.debug...done.
done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
0x00007f2a7de1eb00 in free@plt () from /lib64/ld-linux-x86-64.so.2
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/john/dev/broaty/CrossTest/Debug/CrossTest 
0x00007f1c9a584d50 in ?? ()
gdbserver tells me that there is an incomming connection, but it doesn't write my hello world message.

Any ideas?

Last edited by john_erlandsson; 01-21-2014 at 07:08 PM. Reason: Solved
 
Old 01-17-2014, 10:07 AM   #2
rtmistler
Member
 
Registered: Mar 2011
Location: Milford, MA. USA
Distribution: MontaVista, Ubuntu, MINT
Posts: 754
Blog Entries: 6

Rep: Reputation: 383Reputation: 383Reputation: 383Reputation: 383
Set a breakpoint see if you hit that after you run. I think it is valid what it is telling you; which is that when you attach the process is running and that you have to reset it and run again.

I've done gdb to gdbserver and the sole reason for that is the server did not have an accessible console; the point being I never worried about printf() because whatever I was debugging on the server would write to a log file. I invoked gdbserver via ssh to my target.

After all, if I have a keyboard and screen, then I don't need remote debugging; although I get that you're testing it to validate that it's working. Your case may be working, just that printf() is going somewhere else or stdout/stderr handles are not being shown on the default system console because you're not running that program from the system console, specifically.

This is all why I suggest you set a breakpoint and see if you hit it.

There were other arguments I used because my architecture had the target program running, so I had to specify a PID to attach too in my gdbserver line, much like one attaches to an already running process with a normal gdb session.
 
Old 01-18-2014, 06:38 AM   #3
john_erlandsson
Member
 
Registered: Jul 2009
Location: Sweden
Distribution: Fedora
Posts: 65

Original Poster
Rep: Reputation: 0
I actually tried DDD before posting this. Setting a breakpoint and calling run does nothing.
Allso tried with eclipse (that is the end goal). It is as if the debugger goes to some inaccessible memory and gets itself lost.
 
Old 01-20-2014, 09:26 AM   #4
rtmistler
Member
 
Registered: Mar 2011
Location: Milford, MA. USA
Distribution: MontaVista, Ubuntu, MINT
Posts: 754
Blog Entries: 6

Rep: Reputation: 383Reputation: 383Reputation: 383Reputation: 383
Sorry you're not finding it to just work. Firstly I've never gotten this to work correctly with symbols unless I have the source and binary at the debugger side; where you run gdb; and then on the target obviously have the binary.

Figuring that to be fair I haven't done this in years, I just gave it a try; albeit all on a local machine. And it worked great. I was able to set a breakpoint and hit that but I also saw different information from what you saw as far as the condition of the remote process; it said it was running so I had to continue. Here's how it went:

The program:
Code:
#include <stdio.h>

void main(void)
{
    char *s = "Hello World";
    printf("The address of string s is %p\n", s);
}
Compiling:
Code:
gcc -o test -ggdb test.c
Running gdbserver:
Code:
gdbserver host:9876 test
Process test created; pid = 11231
Listening on port 9876
In other window, my remote debugger

Running GDB
Code:
gdb
GNU gdb (GDB) 7.1-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) target remote 127.0.0.1:9876
Remote debugging using 127.0.0.1:9876
warning: Could not load vsyscall page because no executable was specified
try using the "file" command first.
0xb77fc850 in ?? ()
Loading the symbols:
Code:
(gdb) symbol-file test
Reading symbols from /home/certus/testcode/test...done.
Setting breakpoint at the printf statement:
Code:
(gdb) b test.c:6
Breakpoint 1 at 0x80483f5: file test.c, line 6.
I tried to run and learned that it didn't support it:
Code:
(gdb) run
The "remote" target does not support "run".  Try "help target" or "continue".
So I chose "continue":
Code:
(gdb) c
Continuing.
It hit the breakpoint. That's all I needed to see and so I quit:
Code:
Breakpoint 1, main () at test.c:6
6	    printf("The address of string s is %p\n", s);
(gdb) quit
A debugging session is active.

	Inferior 1 [Remote target] will be killed.

Quit anyway? (y or n) y
Back at the server

It detects that a remote session has started:
Code:
Remote debugging from host 127.0.0.1
Once the remote session is done, it exits:
Code:
Killing all inferiors
So, try this locally with just your machine you are trying to run debugging from and try it locally on your target in the same fashion. Something is missing or incorrect here, it does work.
 
1 members found this post helpful.
Old 01-21-2014, 07:08 PM   #5
john_erlandsson
Member
 
Registered: Jul 2009
Location: Sweden
Distribution: Fedora
Posts: 65

Original Poster
Rep: Reputation: 0
That works. Even compiled with g++ and -std=c++11.

I have tried both target remote (instead of extended-remot) and compiling with -ggdb. But not both at the same time.


That is awesome. Thanks!
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
gdb remote debugging problem unev_21 Linux - Software 1 10-26-2009 09:14 AM
Remote Debugging Shell scripts unev_21 Linux - Software 4 03-12-2009 03:03 PM
debugging remote process in gdb arunachalam Linux - Software 2 02-18-2008 10:27 PM
kernel debugging on remote system urwithsudheer Programming 0 03-23-2006 02:44 AM
FC4 Remote Kernel Debugging gratner Fedora 2 11-02-2005 05:40 PM


All times are GMT -5. The time now is 03:09 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration