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.