From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Vladilen Kozin Newsgroups: gmane.emacs.help,gmane.emacs.tramp Subject: Re: GDB over TRAMP: problem with user I/O Date: Fri, 15 Dec 2017 16:38:56 +0000 Message-ID: References: <87o9n66g2q.fsf@gmx.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1513355996 3362 195.159.176.226 (15 Dec 2017 16:39:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 15 Dec 2017 16:39:56 +0000 (UTC) Cc: help-gnu-emacs@gnu.org, tramp-devel@gnu.org To: Michael Albinus Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Dec 15 17:39:52 2017 Return-path: Envelope-to: geh-help-gnu-emacs@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 1ePt1b-0000YH-Nh for geh-help-gnu-emacs@m.gmane.org; Fri, 15 Dec 2017 17:39:51 +0100 Original-Received: from localhost ([::1]:47532 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ePt1i-0004Yj-Ni for geh-help-gnu-emacs@m.gmane.org; Fri, 15 Dec 2017 11:39:58 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48702) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ePt0m-0004WT-VC for help-gnu-emacs@gnu.org; Fri, 15 Dec 2017 11:39:02 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ePt0l-0001FZ-Ig for help-gnu-emacs@gnu.org; Fri, 15 Dec 2017 11:39:00 -0500 Original-Received: from mail-lf0-x233.google.com ([2a00:1450:4010:c07::233]:43428) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ePt0l-0001Eg-69; Fri, 15 Dec 2017 11:38:59 -0500 Original-Received: by mail-lf0-x233.google.com with SMTP id 101so133732lfs.10; Fri, 15 Dec 2017 08:38:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FuQPGXy9VROSqhwdoQO6Gm2Kly2/+7TOUEtZ5wCphrE=; b=BiUvkbE4yAx8kIgo+4TLX6ZR9zbWyZ3bWHD0BRq3j0YlEJXjyLNUH9QwZrPJVywRek u/ew482fcr/iU8XmBiOutVVDU6OT2G+KVCnBxGGbbiF/UXd1e4Q7BlGTt/TX2R3EkFJl 8D0nV0ZpRnuKiRvFA6FZmozxX/EEFz4zdbpCA+IZ4VWPj2/trxUxx3MjkfrXPSXMAxMT b2W7xUjppCuT5bEHf2wnfeubTnCDcU25lomQdzj+7daIgC4shIBY9hBOqx2099FCKAKu eFuhSYYSD6+COmal7DhUSFS0H3t4xqZKKPfrZxKoLcZGMNF4sCbReDmSPxQdtaBHK0tx T1Mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FuQPGXy9VROSqhwdoQO6Gm2Kly2/+7TOUEtZ5wCphrE=; b=K8P8D7phaBsoauLMloOyBhTm8sSnHYMbfDPBlQqrOtQ+wWMY7Hs2eDfRv5xAIkDxv6 ApfX04X+WtdPv95SCBRANImcoDMMqD6qEP2B9HNulgLroE0adqE0gxrXCZPb1y21GUnS 4MeWXTHBj5Yme06kDIs/nxvaC53cHEN4CnWGPRXdY6x21nGma+tP9M8Wp/eXP71StUaz CxqAUwThI2TyBeNXIqVY9ECPqLe4ndW7L/GBpVJ14kgiK2J46J3i0GED2Ag8WQU4ABwr qBbx1Zx0ip0+M5tAA5/6eltOVelZ9XVUVrf7i8FGFWjfqx2W7/EdXmZbeC/Hhu768AN0 SUFA== X-Gm-Message-State: AKGB3mKBlG4WYZkEnS0SVe86GGQwB5myyZJqq7+QcA7Cc9q9enGTU0Xx n3Z5/YoQ/nQeEGz1sGPFolv9dlflElXo0SZzHFk= X-Google-Smtp-Source: ACJfBosXaLNuhj4Ei0vd27P+q23Jx6kzUfB6ZXKXBfw3FpFej/gItoyt6kLFZTPI4cepsheOoeaHEhBnqRXG5A1tiDA= X-Received: by 10.25.17.24 with SMTP id g24mr2782952lfi.132.1513355937269; Fri, 15 Dec 2017 08:38:57 -0800 (PST) Original-Received: by 10.25.206.139 with HTTP; Fri, 15 Dec 2017 08:38:56 -0800 (PST) In-Reply-To: <87o9n66g2q.fsf@gmx.de> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4010:c07::233 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:115364 gmane.emacs.tramp:9235 Archived-At: 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 wrote: > 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. -- Best regards Vlad Kozin