0

I am using gdb to debug the following program in ubuntu 16.04.

#include<iostream>
using namespace std;
int main() {
    int n;
    cin>>n;
    cout<<n<<endl;
    return 0;
}

When I debug it locally, I am able to input data using keyboard. However, when I debug using gdb server, I get stuck when I try to input data using stdin. Does anyone know how to fix this problem?

Casualet
  • 295
  • 3
  • 12
  • You could run your program, find the process ID (e.g., xxxx) for the program. Open gdb with "$ gdb -pid xxxx"or if gdb is open "(gdb) attach xxxx". You may need to sudo gdb first. This works better if you are using screen or tmux, etc. – InfinitelyManic Feb 08 '17 at 00:21

1 Answers1

3

Unfortunately, gdbserver won't help you in this case (for now). It simply starts the program using gdbserver's tty, which is on the remote machine. This is unfortunate because GDB remote protocol has extensions to manage this, but gdbserver doesn't implement it (so far).

So you have to manage your program's tty yourself. The most complete solution is using socat to create a "remote TTY" for you and your program.

On the remote machine:

$ socat TCP-LISTEN:12345 EXEC:'<your program>',ptmx

The option ptmx allows to use a PTY as inter-process communication mechanism instead of a socketpair. It will give you finer grained control on buffering using tty settings, directly built in socat's CLI (cf. man socat). In this default case, it simply buffers until a newline character is written by <your program>.

On the other side, run:

$ socat - TCP:localhost:12345

And now you have your remote TTY, besides GDB's.
It supposes that you can run socat on your target and that you can connect to it through a TCP network.

If you can't, you could also use a free serial line, stty your settings and run your program against it using shell redirections:

$ stty -F /dev/ttyUSB0 raw 9600
$ exec command <> /dev/ttyUSB0 >&0 2>&1

As explained in this answer.

Anyway, you definitely should wrap your solution and gdbserver has a --wrapper option allowing you to script the way the program is run when using --multi.

Note that using multi-inferior solutions to remotely run socat and automatically attach to the forked program, the one you want to debug, are too buggy for now to be explained and used.

Community
  • 1
  • 1
Julio Guerra
  • 5,523
  • 9
  • 51
  • 75