From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28150 invoked by alias); 6 Dec 2013 20:44:51 -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 28140 invoked by uid 89); 6 Dec 2013 20:44:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from Unknown (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 06 Dec 2013 20:44:49 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rB6Kig6Y002012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 6 Dec 2013 15:44:42 -0500 Received: from barimba (ovpn-113-93.phx2.redhat.com [10.3.113.93]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rB6KieED007547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 6 Dec 2013 15:44:41 -0500 From: Tom Tromey To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [PATCH v4 9/9] enable target-async References: <1382464769-2465-1-git-send-email-tromey@redhat.com> <1382464769-2465-10-git-send-email-tromey@redhat.com> <52828856.9070904@redhat.com> <87li0qve9y.fsf@fleche.redhat.com> <528A2E8B.9050300@redhat.com> Date: Fri, 06 Dec 2013 20:44:00 -0000 In-Reply-To: <528A2E8B.9050300@redhat.com> (Pedro Alves's message of "Mon, 18 Nov 2013 15:13:15 +0000") Message-ID: <87r49piu9z.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2013-12/txt/msg00272.txt.bz2 >>>>> "Pedro" == Pedro Alves writes: Pedro> Sorry, I wasn't clear. I understand what as a whole the patch is trying Pedro> to do; what I don't understand is why a hack was necessary, or its Pedro> implementation. E.g., what exactly fails if the hack is not Pedro> in place?; Why this spot for the hack?; What's the predicate used in Pedro> the hack actually checking? I don't remember, but I'll back it out and redo the analysis to find out. Pedro> Now that I looked again a little closer, I recalled that GDB in Pedro> sync mode always outputs a silly extra prompt right after Pedro> ^running (in response to execution commands), before the target Pedro> stops, even though GDB is not ready for input then. Guess this Pedro> hack is related? Probably so. To my surprise dealing with the prompt was by far the most difficult part of this series. Doubly sad since the prompt just seems like a mistake to me in the first place. >> set target-async on >> &"set target-async on\n" >> ^done >> (gdb) >> -list-target-features >> ^done,features=["async"] Pedro> I guess we could see it either way. -list-target-features lists Pedro> target features. So with GDB today, until "set target-async on" Pedro> is issued, the target doesn't support async. After the series, Pedro> the target does support async even if MI itself isn't async. Pedro> E.g., I'd've expected 'interpreter-exec mi "-list-target-features"' Pedro> issued from the cli to list "async". Pedro> Given the chicken and egg thing already exists today, this makes Pedro> me think no frontend is actually looking for this feature... (?) Pedro> Anyway, fine with me to leave this as you have it for now, and Pedro> maybe reconsider it after the series is in. Yeah. My overall goal for this series was to eliminate the need for "set target-async on", while at the same time preserving the current MI output, regardless of whether I felt it was correct; unless said change is clearly compatible according to the normal MI rules. My reasoning is that this is the best way to avoid breaking a client. >>>> -# so the stop reason is printed into MI uiout an. >>>> -if {$async} { >>>> - set reason "end-stepping-range" >>>> -} else { >>>> - set reason "" >>>> -} >>>> +set reason "end-stepping-range" >> Pedro> I'm a little confused by this one. Isn't it still necessary Pedro> for targets that don't do async? I re-examined this and I think the answer is much simpler than all the incorrect things I wrote before. git master gdb in the default (target-async off) mode prints: *stopped,frame={addr="0x0000000000400597",func="callee4",args=[],file="../../../binutils-gdb/gdb/testsuite/gdb.mi/basics.c",fullname="/home/tromey/Space/SecondArcher/binutils-gdb/gdb/testsuite/gdb.mi/basics.c",line="26"},thread-id="1",stopped-threads="all",core="0" The gdb from this branch prints: *stopped,reason="end-stepping-range",frame={addr="0x0000000000400597",func="callee4",args=[],file="../../../binutils-gdb/gdb/testsuite/gdb.mi/basics.c",fullname="/home/tromey/gnu/gdb/devel/binutils-gdb/gdb/testsuite/gdb.mi/basics.c",line="26"},thread-id="1",stopped-threads="all",core="3" That is, gdb now emits reason="end-stepping-range". This is a compatible change to the output. This explains the patch: now the !$async case is no longer hit. Tom