From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 108771 invoked by alias); 6 May 2016 12:58:13 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 108756 invoked by uid 89); 6 May 2016 12:58:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.0 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=responds, Issues X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 06 May 2016 12:58:02 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C1B7868D; Fri, 6 May 2016 12:58:01 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u46Cw06G013005; Fri, 6 May 2016 08:58:01 -0400 From: Pedro Alves Subject: Re: [PATCH v2 00/25] Towards great frontend GDB consoles To: Marc Khouzam , "gdb-patches@sourceware.org" References: <1458573675-15478-1-git-send-email-palves@redhat.com> <56F042BF.7000700@redhat.com> Message-ID: Date: Fri, 06 May 2016 12:58:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <56F042BF.7000700@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-05/txt/msg00133.txt.bz2 On 03/21/2016 06:51 PM, Pedro Alves wrote: > >> > 2- Using 'interpreter-exec mi" in the CLI console confuses GDB >> > To reproduce from a shell >> > - start GDB in CLI mode >> > - give a "new-ui mi" command to start an MI channel >> > - start running the inferior => *stopped/*running events are on the MI channel >> > - in the CLI send command interpreter-exec mi "" >> > - step or resume >> > => *stopped/*running events are now on the CLI channel and not the MI one > I can reproduce this. > > This may be related to the fact that MI's code still has a bunch of > globals that I hadn't made per-UI, thinking that that would be sufficient > for the use case at hand. While annoying, I wouldn't expect a > regular user / script to be issuing MI commands, right? For the record, this was indeed related to MI globals. Specifically, "raw_stdout". Fixed by making it be per-MI instead: https://sourceware.org/ml/gdb-patches/2016-05/msg00130.html >> > >> > 3- Issues when using "set inferior-tty" >> > To reproduce from a shell >> > - start GDB in CLI mode >> > - give a "new-ui mi" command to start an MI channel >> > - use "set inferior-tty" to another tty (like eclipse does) >> > - in the MI channel, use -exec-run >> > => the shell where GDB CLI is running no longer responds to input > Interesting. I can reproduce this as well. I wonder if it's > related to PR gdb/18077 (-exec-run results in synchronous execution), > but then again, it doesn't reproduce without "set inferior-tty". This was related to an issue with how gdb starts inferiors. It vforks, then uses ptrace (PTRACE_ME), and then execs. Between the vfork and the exec, the child was running with the MI channel as current UI, and because it's a vfork, that messed up the parent gdb's structures. Fixed here, with a testcase that ensures that "set inferior-tty" use cases are correctly handled: https://sourceware.org/ml/gdb-patches/2016-05/msg00128.html Thanks, Pedro Alves