From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.tramp,gmane.emacs.help Subject: Re: GDB over TRAMP: problem with user I/O Date: Sun, 10 Dec 2017 11:19:09 +0100 Message-ID: <87o9n66g2q.fsf@gmx.de> References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1512901159 18101 195.159.176.226 (10 Dec 2017 10:19:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 10 Dec 2017 10:19:19 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) Cc: help-gnu-emacs@gnu.org, tramp-devel@gnu.org To: Vladilen Kozin Original-X-From: tramp-devel-bounces+get-tramp-devel=m.gmane.org@gnu.org Sun Dec 10 11:19:14 2017 Return-path: Envelope-to: get-tramp-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eNyhV-0004Tc-Ld for get-tramp-devel@m.gmane.org; Sun, 10 Dec 2017 11:19:13 +0100 Original-Received: from localhost ([::1]:44059 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eNyhc-0008Jx-E8 for get-tramp-devel@m.gmane.org; Sun, 10 Dec 2017 05:19:20 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58546) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eNyhY-0008Jh-Kk for tramp-devel@gnu.org; Sun, 10 Dec 2017 05:19:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eNyhV-00055K-EL for tramp-devel@gnu.org; Sun, 10 Dec 2017 05:19:16 -0500 Original-Received: from mout.gmx.net ([212.227.17.21]:64154) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eNyhV-00054h-4Y; Sun, 10 Dec 2017 05:19:13 -0500 Original-Received: from detlef.gmx.de ([212.86.60.132]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MSq5p-1eVVlr3t2b-00RoQm; Sun, 10 Dec 2017 11:19:11 +0100 X-Provags-ID: V03:K0:1USu4DEFSefMNHdC0IQbYZ15a0Y8HHM2kGZfx2t7ANPNUjinDPq pRt2rGm7gFTVB8kU1Y2LAfXrx7V/tDyw6+Dqb6p15+dnnnyTaBDyPUqcaPjtz/E4dImcssP iTI+jIjOI1Brl/38ByTr0FWJCt3BIYNgFELjpxl6QheuUiJl6ZcRCrFoZHqdsEE0A5p9obL cK2zok/Y1ZLomgXUxpt5w== X-UI-Out-Filterresults: notjunk:1;V01:K0:bby9OQOwoaA=:G6UvTNhLtC1eH3haJ+5hq6 DttSydYoZVbJNm0cZLAokEocbyDFH2L7RC91QkgR42mE48r5CktX0fcPeys0IU/o6UT/cY579 76kjwEY66EWvj7LEnDToicUVhCzoTiXrHd4RCbYBRbCajOMaq1rg3QzeA/L3ZZhTg8U7qcZ8Z lIi6A7tyeYcwXYDFuPtYE3a8sUy4YQ2NqjmDBJRxs2l4zQ10p1HPzvR3Jc8v9k52WBF+JkB5W UwU7zwx9nbbRTSL6UY1Ts0blNVMyIumZP/eJL3FQAoB4Wo9sMt0zJiJJIaIHD5KrmoIr3hexx 8cCk4NYH8q4jPJGlg1OaGr99xVha9vFuWgaWlu9SmTjPR85Lzfv4rCPbXO9Zbl5CjEmInN1pb VMJZbBWdeWVQ0JbdMYKFiv+vS/DYDoIFnlD0y9M2NcjZpERwnjEAo5Gumniejk9PARUnokITP /QBu47Hk7NoHqTm3wM+D4KYJRz3Flk2QqPgdb3SY2i96Aci+ScvrQcMAY6brXtYkZQIw0c5eW Bz++kTtapG50GcsbSQNztXA2x8t4aD5xwfCiGSrCmE2ESvHx1OC1tKpMzkIFXp7xdZ/iGGkuy wQ9hYVlUes2o24NnCXdhfzcwNY1PUjttehzIwK4nt2s2cEdYXAjNRw0hpCe2Pyvm43dSzwWfV 0+gwgnrIm5++pWOsnhphS5KRG4KnWXwZ33r8KPzmLzvtBUMaHwdrgmm/Xv2r5Z5TAedFb4vg0 UntZB5tyZ6Xm4PUYa7wgBjNSoJHOeFGoKWsKdxePo4tBM0cL014IaFaKfMpBRZ4RUYatj72Z X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 212.227.17.21 X-BeenThere: tramp-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tramp-devel-bounces+get-tramp-devel=m.gmane.org@gnu.org Original-Sender: "Tramp-devel" Xref: news.gmane.org gmane.emacs.tramp:9231 gmane.emacs.help:115322 Archived-At: Vladilen Kozin 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- (bound to buffer *gud-*), which is the gdb process itself, and gdb-inferior (bound to buffer *input/output of *), 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 * interactively. I have no idea how to fix this. Handling remote ttys simply does not work as gdb expects. Best regards, Michael.