Remote debugging problems [SOLVED]

john_erlandsson · 01-15-2014, 05:25 PM

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?

rtmistler · 01-17-2014, 10:07 AM

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.

john_erlandsson · 01-18-2014, 06:38 AM

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.

rtmistler · 01-20-2014, 09:26 AM

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.

john_erlandsson · 01-21-2014, 07:08 PM

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!