From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27148 invoked by alias); 13 Jul 2015 19:20:54 -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 27136 invoked by uid 89); 13 Jul 2015 19:20:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 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; Mon, 13 Jul 2015 19:20:52 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 2DAD62B7841; Mon, 13 Jul 2015 19:20:50 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t6DJKmPV025423; Mon, 13 Jul 2015 15:20:48 -0400 Message-ID: <55A40F90.7060904@redhat.com> Date: Mon, 13 Jul 2015 19:20:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Simon Marchi , Joel Brobecker CC: gdb-patches Subject: Re: Should this be on the blocker list for the 7.10 release? References: <559AE482.1010109@ericsson.com> <20150707132459.GA16734@adacore.com> <559BFBBD.4000303@redhat.com> <559C14B6.5020800@redhat.com> <559C1BFB.7070308@ericsson.com> <559C1EA9.5090400@redhat.com> <559C22D1.7020501@redhat.com> <559C268E.4050706@redhat.com> <559C4CED.1030506@ericsson.com> In-Reply-To: <559C4CED.1030506@ericsson.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-07/txt/msg00384.txt.bz2 On 07/07/2015 11:04 PM, Simon Marchi wrote: > Another question. This is probably unrelated to the current issue, since > the behavior was the same in 7.9, but I am encountering it while writing > the test. When running the program without the &, when should the prompt > come back? Yes, it's an issue currently that the prompt returns too eagerly. It's "always" been that way though, not just in 7.9. Your example was non-stop mode, but I'd say all-stop mode is even worse. Consider the scenario of debugging the canonical multi-process example (debug "make check" until some child process crashes). Currently everything stops as soon as any child process exits... > > See this transcript: http://pastebin.com/qyba8Ucd > > We see that the prompt comes back the first time an inferior exits, well > before the end of the execution of inferior #1. I would think that this > is not what we want. If I run my program synchronously, then the inferior > forks and then the fork child exits, do we really want to bring back the > prompt at this point? I would think that we should only show it when > the initial inferior that was ran exits (or if some other significant > event, such as a breakpoint hit, of course). Yeah, I think we need something like this. But should the prompt be shown if the parent exits but the child carries on? Why? How do you define which process is special? I think we should think of "run" as "create process" + "continue". Because, say, you do "start", followed by "continue", and then the inferior forks, and then child exits. It's the same situation. Or any execution command really. E.g., what if you already have two processes under control of the debugger, and step a thread of inferior 2, while running all threads of all processes free (all-stop + schedule-multi on), and inferior 1 exits while the step is still in progress? It's not even clear if the prompt should be returned when a breakpoint hits. Since I know you've played with my itsets branch, let me put this in terms of that branch: Say you do "itfocus it1.1 next". While "next" is in progress, a thread from some other inferior (that was already running) hits a breakpoint, and that breakpoint's suspend set does _not_ stop thread 1.1. It would seem that it would be reasonable to say that the "next" really hasn't finished yet, and thread 1.1 should continue stepping? It would follow then that the prompt shouldn't be returned to the user yet. Maybe what we need is for synchronous commands to define the set of threads they're waiting for. In "itfocus it1.1 next", it would wait until any thread in inferior 1 reports a stop. In "itfocus tt1.1 next", it would wait until thread 1.1 reports a stop. In "itfocus at1.1 next", it would wait until any thread reports a stop. Etc. Since you can only run one synchronous command at a time, the set of what to wait before the prompt is given back to the user would be a property of the interpreter, not the thread. > > Would you agree? > I agree, though the devil is in the details. I'd rather not try to fix this for 7.10. Thanks, Pedro Alves