Hi Michael, thank you very much for digging into it. I played with ttys, too, and had somewhat similar experience perhaps with less understanding on my part. Similar bug plagues a ton of external debugging tools that interface with GDB: google spits out a ton of complaints in code blocks, netbeans, etc that's been popping up at least since 2009. All suggested "solutions" amount to cargoculting some nonsense that on occasion works.
There's one bug reported to GDB bugtracker ages ago that remains open and might be of note: https://sourceware.org/bugzilla/show_bug.cgi?id=11403 I've also updated to the latest version of everything just to confirm the issue is present in the latest GDB - it is. I'll see if I really want to dig deeper there. The only reason I went with this remote debugging setup is cause OSX has become notoriously hostile to GDB, so thought I might spin a Linux box with Vagrant and run all my probes this way with Emacs acting a thin client. Would've been cool. Still, Tramp is incredible piece of software - I'm in awe. Will report back if discover smth noteworthy. Best On 10 December 2017 at 10:19, Michael Albinus <[email protected]> wrote: > Vladilen Kozin <[email protected]> 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: > albinus@pts/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. -- Best regards Vlad Kozin _______________________________________________ Tramp-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/tramp-devel
