From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19084 invoked by alias); 23 May 2014 20:45:23 -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 19063 invoked by uid 89); 23 May 2014 20:45:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_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 ESMTP; Fri, 23 May 2014 20:45:21 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s4NKjKpt023927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 23 May 2014 16:45:20 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s4NKjIw1009322; Fri, 23 May 2014 16:45:19 -0400 Message-ID: <537FB35E.7090309@redhat.com> Date: Fri, 23 May 2014 20:45:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [RFC v5 7/8] separate MI and target notions of async References: <1393957974-4521-1-git-send-email-tromey@redhat.com> <1393957974-4521-8-git-send-email-tromey@redhat.com> In-Reply-To: <1393957974-4521-8-git-send-email-tromey@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-05/txt/msg00594.txt.bz2 On 03/04/2014 06:32 PM, Tom Tromey wrote: > This separates the MI and target notions of "async". > > Unlike the CLI, MI chose to treat target-async specially -- setting it > changes the default behavior of commands. So, we can't get rid of the > option. Instead we have to make it MI-only. > > Rather than make the targets always async, this patch introduces a new > "maint" parameter so that the gdb developer can control whether the > target is async. This makes it simpler to debug issues arising only > in the synchronous mode; important because it sync mode seems unlikely > to go away. > > Note that "set target-async" also affects this new maint parameter. > The rationale for this is that then one can easily run the test suite > in the "maint set target-async off" mode and have tests which enable > target-async continue to work properly. This is unusual but, but it > is a maint command after all, and this behavior is useful. As discussed, v6 will not have this coupling. the idea is that "maint set target-async off" emulates a non-async-capable target, so "maint set target-async off" + "set target-async on" + "c&" should result in failure to run a background command, just like e.g., if one tries "set target-async on" + "c&" on Windows. In v6, I'm proposing adding an "set mi-async" option, and making "set target-async" a deprecated alias for "set mi-async" going forward, to avoid confusion. > > The hardest part of this patch, to my surprise, was getting the MI > prompt to work properly. It was reasonably easy, and clean, to get > close to what the test suite expects; but to fix the last remaining > failure (mi-async.exp), I had to resort to a hack. I think I found a cleaner way to do this. v6 will include it. > /* Command implementations. FIXME: Is this libgdb? No. This is the MI > layer that calls libgdb. Any operation used in the below should be > formalized. */ > @@ -260,6 +269,11 @@ exec_continue (char **argv, int argc) > { > struct cleanup *back_to = make_cleanup_restore_integer (&sched_multi); > > + /* If MI is in sync mode but the target is async, then > + normal_stop enabled stdin. We undo the change here. */ This comment threw me off for a while. It doesn't matter what normal_stop did in a previous command. The code below is actually correct, in as much as we need to do that before all execution commands. We can now just call prepare_execution_command to do it for us. > + if (!target_async_permitted && target_can_async_p ()) > + async_disable_stdin (); > diff --git a/gdb/testsuite/gdb.mi/mi-cli.exp b/gdb/testsuite/gdb.mi/mi-cli.exp > index e158b7e..8cfab3b 100644 > --- a/gdb/testsuite/gdb.mi/mi-cli.exp > +++ b/gdb/testsuite/gdb.mi/mi-cli.exp > @@ -134,20 +134,9 @@ mi_gdb_test "500-stack-select-frame 0" \ > {500\^done} \ > "-stack-select-frame 0" > > -# When a CLI command is entered in MI session, the respose is different in > -# sync and async modes. In sync mode normal_stop is called when current > -# interpreter is CLI. So: > -# - print_stop_reason prints stop reason in CLI uiout, and we don't show it > -# in MI > -# - The stop position is printed, and appears in MI 'console' channel. > -# > -# In async mode the stop event is processed when we're back to MI interpreter, > -# so the stop reason is printed into MI uiout an. > -if {$async} { > - set reason "end-stepping-range" > -} else { > - set reason "" > -} > +# Allow a reason, or not. Which we get depends at least on whether > +# the target being tested supports async. > +set reason ".*" This patch gets rid of this in the opposite direction: https://sourceware.org/ml/gdb-patches/2014-05/msg00566.html > mi_execute_to "interpreter-exec console step" $reason "callee4" "" ".*basics.c" $line_callee4_next \ > "" "check *stopped from CLI command" > diff --git a/gdb/testsuite/lib/mi-support.exp b/gdb/testsuite/lib/mi-support.exp > index 213073a..16c7951 100644 > --- a/gdb/testsuite/lib/mi-support.exp > +++ b/gdb/testsuite/lib/mi-support.exp > @@ -1096,7 +1096,9 @@ proc mi_expect_stop { reason func args file line extra test } { > } > > set r "" > - if { $reason != "" } { > + if { $reason == ".*" } { > + set r "(?:reason=\".*\",)?" > + } elseif { $reason != "" } { > set r "reason=\"$reason\"," > } > And ends up no longer necessary. v6 coming up... Getting close. :-) -- Pedro Alves