From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13832 invoked by alias); 2 Nov 2012 10:28:21 -0000 Received: (qmail 13806 invoked by uid 22791); 2 Nov 2012 10:28:20 -0000 X-SWARE-Spam-Status: No, hits=-4.5 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; Fri, 02 Nov 2012 10:28:13 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1TUEU1-0006ep-Cu from Ali_Anwar@mentor.com for gdb-patches@sourceware.org; Fri, 02 Nov 2012 03:28:13 -0700 Received: from SVR-ORW-FEM-03.mgc.mentorg.com ([147.34.97.39]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Nov 2012 03:28:13 -0700 Received: from [137.202.157.121] (147.34.91.1) by SVR-ORW-FEM-03.mgc.mentorg.com (147.34.97.39) with Microsoft SMTP Server (TLS) id 14.1.289.1; Fri, 2 Nov 2012 03:28:04 -0700 Message-ID: <5093A00C.2000700@codesourcery.com> Date: Fri, 02 Nov 2012 10:28: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> <508FBF88.2060102@codesourcery.com> In-Reply-To: <508FBF88.2060102@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-11/txt/msg00035.txt.bz2 On 10/30/2012 04:52 PM, ali_anwar wrote: > 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. > > Ping.. Is it OK to commit? -Ali