Re: GDB over TRAMP: problem with user I/O

[Michael Albinus]

Vladilen Kozin <address@hidden> writes:

Hi Vladilen,

> Ran into problem with GDB over TRAMP. To me it looks like a bug in TRAMP
> but could be that I've missed some settings required for such setup. Hence
> posting here instead of bugs for now.

First of all, I could reproduce it. But I'm not sure it is a Tramp
error. Rather a missing feature.

I've tried to understand how gdb is working. Took a while, I'm not
familiar with that code. After gdb has been called, it starts to
asynchronous processes: gud-<program> (bound to buffer *gud-<program>*),
which is the gdb process itself, and gdb-inferior (bound to buffer
*input/output of <program>*), which does not run any program, but
allocates a tty only. You'll see this when calling "M-x list-processes".

--8<---------------cut here---------------start------------->8---
gdb-inferior    -2      run     *input/outpu... /dev/pts/4   
gud-debug       30367   run     *gud-debug*     /dev/pts/3   gdb -i=mi debug
--8<---------------cut here---------------end--------------->8---

Look at the local case: In the gdb-debug buffer, I've checked the used tty:

--8<---------------cut here---------------start------------->8---
(gdb) show inferior-tty
Terminal for future runs of program being debugged is "/dev/pts/4".
--8<---------------cut here---------------end--------------->8---

Starting the test program, and checking outside Emacs for pts/4, you'll
see that it is used by the gdb process:

--8<---------------cut here---------------start------------->8---
$ ps -eaf | grep pts/4
albinus  30405 30367  0 11:07 pts/4    00:00:00 /home/albinus/tmp/fact/debug
--8<---------------cut here---------------end--------------->8---

Now I have performed the remote case. For simplicity, I have just
prepended "/ssh::" to the test files, that's sufficient. The process
list looks different:

--8<---------------cut here---------------start------------->8---
*tramp/ssh d... 30451   run     *tramp/ssh d... /dev/pts/3   /bin/sh -i
gdb-inferior    30764   run     *input/outpu... /dev/pts/7   /bin/sh -i
gud-debug       30740   run     *gud-debug*     /dev/pts/5   /bin/sh -i
--8<---------------cut here---------------end--------------->8---

You see, that the gdb-inferior does not return just a tty. This is not
possible for remote processes. Instead, it is bound to /dev/pts/7, the
tty of the running remote shell.

In the gdb buffer, I've checked the used tty, again:

--8<---------------cut here---------------start------------->8---
(gdb) show inferior-tty
Terminal for future runs of program being debugged is "/dev/pts/8".
--8<---------------cut here---------------end--------------->8---

Starting the test program, you'll see a different situation:

--8<---------------cut here---------------start------------->8---
$ ps -eaf | grep pts/8
albinus  30567 30452  0 11:09 ?        00:00:00 sshd: 
address@hidden/4,pts/6,pts/8
albinus  30765 30567  0 11:09 pts/8    00:00:00 /bin/sh
albinus  30927 26061  0 11:14 pts/9    00:00:00 grep pts/8
$ ps -eaf | grep fact
albinus  22347 22258  0 11:21 ?        00:00:00 /home/albinus/tmp/fact/debug
albinus  22377 31587  0 11:22 pts/0    00:00:00 grep fact
--8<---------------cut here---------------end--------------->8---

The test program, debug, has no tty. And gdb tries to communicate with
tty pts/8, which is the remote shell. Well, this cannot work. gdb tells
you this with the message &"warning: GDB: Failed to set controlling
terminal: Operation not permitted\n". Instead, your program is
communicating with the shell which owns /dev/pts/8. You will see, that
you could use the buffer *input/output of <program>* interactively.

I have no idea how to fix this. Handling remote ttys simply does not
work as gdb expects.

Best regards, Michael.