From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22486 invoked by alias); 14 Nov 2012 18:29:05 -0000 Received: (qmail 22477 invoked by uid 22791); 14 Nov 2012 18:29:03 -0000 X-SWARE-Spam-Status: No, hits=-7.7 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 14 Nov 2012 18:28:51 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qAEISnbt005408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Nov 2012 13:28:49 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id qAEISkZ0005678; Wed, 14 Nov 2012 13:28:47 -0500 Message-ID: <50A3E2DE.2060200@redhat.com> Date: Wed, 14 Nov 2012 18:29:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: lgustavo@codesourcery.com CC: Tom Tromey , ali_anwar , dje@google.com, Yao Qi , gdb-patches@sourceware.org, Vladimir Prus Subject: Re: Patch to propagate GDB's knowledge of the executing state to frontend References: <50891E05.7050509@codesourcery.com> <508F719C.2080409@codesourcery.com> <20627.61842.606081.697743@ruffy2.mtv.corp.google.com> <50941519.6010005@codesourcery.com> <509D5E19.5060409@redhat.com> <509D8B21.2040804@codesourcery.com> <87wqxp414y.fsf@fleche.redhat.com> <50A2C88B.6070105@codesourcery.com> In-Reply-To: <50A2C88B.6070105@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 X-SW-Source: 2012-11/txt/msg00380.txt.bz2 On 11/13/2012 10:24 PM, Luis Machado wrote: > On 11/13/2012 07:57 PM, Tom Tromey wrote: >> Luis> Should frontends relying on MI information treat ^error specially and >> Luis> not look for any *stopped records? >> >> I don't know the answer to this. I did find this though: >> >> http://sourceware.org/bugzilla/show_bug.cgi?id=7778 >> >> I tend to think it would be cleanest if gdb were to emit a *stopped in >> case of error -- but only if it previously emitted *running. I don't >> know how feasible this is. > > Right. That seems to be what Ali's patch is attempting to address, in order to improve the relationship with the frontends. It might be a worthy goal (*), but IIUC that patch breaks things like define foo step step end where an error happens while handling the first step, we'll go on with the command list anyway, instead of canceling the whole canned command. (*) - though if the frontend is going to do a full refresh I don't see that much point. > >> >> Luis> The MI specification gives room for slightly different interpretations >> Luis> unfortunately. >> >> For me, the text for "*running" is pretty clear: >> >> The frontend should assume that no interaction with a >> running thread is possible after this notification is produced. >> >> I'm curious where the text is that gives room for another approach. Well, an "except when things go wrong" is missing here. :-) > I wanted to know what is to be done once an ^error is thrown at the frontend and how it should behave. > > There is this text: > > "There's no guarantee that whenever an MI command reports an error, gdb or the target are in any specific state, and especially, the state is not reverted to the state before the MI command was processed. Therefore, whenever an MI command results in an error, we recommend that the frontend refreshes all the information shown in the user interface." > > It is not clear how things need to be refreshed, specially when the frontend needs to assume a thread/inferior is still running after it saw ^running but did not see a *stopped record, though it did see an ^error. But ^error does not imply the target has stopped. > > So it needs to refresh information, but should it forget the target was running and attempt to fetch data anyway or should it do something else? > > In the case of all-stop mode, we know the inferior is stopped. This may not be true for non-stop though. Yes, this is what I was alluding to when I said that an error, frontends should just no longer trust any of their state, and issue a full refresh. I assumed frontends to be already doing this. -thread-info includes a "state" field for each thread that says whether the thread is running or not. The finish_thread_state_cleanup cleanups are there to make sure the "state" field ends up correct on errors: -thread-info ^done,threads=[{id="1",target-id="Thread 0x7ffff7fce740 (LWP 26570)",name="gdb",frame={level="0",addr="0x0000000000457bcb",func="main",args=[{name="argc",value="1"},{name="argv",value="0x7fffffffdc78"}],file="../../src/gdb/gdb.c",fullname="/home/pedro/gdb/mygit/src/gdb/gdb.c",line="29"},state="stopped",core="0"}],current-thread-id="1" (gdb) I guess this means the frontend in question is either not issuing that command, or not reading that "state" field. -- Pedro Alves