From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5027 invoked by alias); 30 Oct 2012 11:53:30 -0000 Received: (qmail 5006 invoked by uid 22791); 30 Oct 2012 11:53:29 -0000 X-SWARE-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 30 Oct 2012 11:53:20 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1TTANj-0002m1-Ny from Ali_Anwar@mentor.com for gdb-patches@sourceware.org; Tue, 30 Oct 2012 04:53:19 -0700 Received: from SVR-ORW-FEM-05.mgc.mentorg.com ([147.34.97.43]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Oct 2012 04:53:19 -0700 Received: from [137.202.157.121] (147.34.91.1) by mail-na.mentorg.com (147.34.97.43) with Microsoft SMTP Server (TLS) id 14.1.289.1; Tue, 30 Oct 2012 04:53:18 -0700 Message-ID: <508FBF88.2060102@codesourcery.com> Date: Tue, 30 Oct 2012 11:53:00 -0000 From: ali_anwar User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: Yao Qi CC: Subject: Re: Patch to propagate GDB's knowledge of the executing state to frontend References: <50891E05.7050509@codesourcery.com> <508F719C.2080409@codesourcery.com> In-Reply-To: <508F719C.2080409@codesourcery.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes 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-10/txt/msg00541.txt.bz2 On 10/30/2012 11:20 AM, Yao Qi wrote: > On 10/25/2012 07:09 PM, ali_anwar wrote: >> Hi, >> >> Attached patch is to let GDB propagate the target state under following >> two scenarios: >> >> 1. Attached patch will enable GDB to inform about the state of the >> target when it was not able to fetch the non-general registers, when >> target is already stopped. >> >> The reason behind this behavior was an error message which was caused >> when the GDB was not able to fetch the value of a certain register. The >> GDB should have told the front end about the current state of the >> target. The attached patch makes sure that it happens. This patch should >> be a safety measure in case some debugging stub behaves badly. >> >> 2. Attached patch will enable GDB to inform about the state of the >> target when it was not able to fetch the backtrace once the step has >> already occurred and target is in stopped state. >> > > It is better to describe what will happen or what is wrong if this patch > is not applied. > Thanks Yao for the review. Let me restate the actual problem: Under certain scenarios, GDB is unable to specify the correct target state once the step/finish instruction is executed. 1. If you perform a step out (finish) and there is an error when GDB tries to fetch the register values. 2. If you perform a ste and there is an error when GDB tries to fetch the backtrace. In both the cases the only output is an error message and nothing is printed as far as current target state is concerned.e.g. (gdb) -exec-finish ^running *running,thread-id="all" (gdb) ^error,msg="Could not fetch register \"\"; remote failure reply 'E22'" (gdb) In other words from MI's perspective, the step hasn't completed yet – the state is still "running". The only concern is GDB not printing the state of the target. It does not matter why the error occurred. >> + executing state to frontend when not able to fetch registers. >> + (wait_for_inferior): Chnage to propagate GDB's knowledge of > ^^^^^^ typo > > >> + the executing state if not able to fetch backtrace once the >> + step has already occured. > ^^^^^^^ typo. > I will fix the both typos. > In each changelog entry, we'll put 'what do we change' instead of 'why > do we change in this way'. So this entry can be simplified. > I will look into it as well. >> + handle_inferior_event (ecs); >> + return (0); > > parentheses are not needed. > >> +} >> + >> + return (0); > > Likewise. > I will remove the parentheses. Thanks, -Ali