[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GDB over TRAMP: problem with user I/O
From: |
Michael Albinus |
Subject: |
Re: GDB over TRAMP: problem with user I/O |
Date: |
Sun, 10 Dec 2017 11:19:09 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) |
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.