From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31653 invoked by alias); 11 Apr 2012 10:44:32 -0000 Received: (qmail 31624 invoked by uid 22791); 11 Apr 2012 10:44:31 -0000 X-SWARE-Spam-Status: No, hits=-3.9 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; Wed, 11 Apr 2012 10:44:18 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1SHv29-0006wz-PN from Yao_Qi@mentor.com for gdb-patches@sourceware.org; Wed, 11 Apr 2012 03:44:17 -0700 Received: from SVR-ORW-FEM-05.mgc.mentorg.com ([147.34.97.43]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 03:44:17 -0700 Received: from [127.0.0.1] (147.34.91.1) by svr-orw-fem-05.mgc.mentorg.com (147.34.97.43) with Microsoft SMTP Server id 14.1.289.1; Wed, 11 Apr 2012 03:44:15 -0700 Message-ID: <4F85607A.3090205@codesourcery.com> Date: Wed, 11 Apr 2012 10:53:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Hui Zhu CC: Subject: Re: [PATCH] breakpoint remove fail handle bug fix References: <4F8549BC.3050003@mentor.com> In-Reply-To: <4F8549BC.3050003@mentor.com> Content-Type: text/plain; charset="UTF-8" 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-04/txt/msg00238.txt.bz2 Here are some my thoughts on this problem. I didn't read patch carefully, so have no comments on it. On 04/11/2012 05:07 PM, Hui Zhu wrote: > This because is when GDB got fail when it remove the breakpoint, it give > up the control of this breakpoint. You are removing breakpoints when inferior is in background execution. It is expected or reasonable that GBD is unable to remove breakpoint instructions from inferior when it is running (due to ptrace limitation IIRC). > There are 2 issues about it: > 1. When the GDB stop, this breakpoint is not be removed. This is because breakpoint instances (not breakpoint instructions written in inferior) was remove when inferior is running. When inferior stops, breakpoint instructions are not removed from inferior, because there is no breakpoint instances in GDB. Current policy in GDB is that even we get something wrong in removing breakpoints, still remove them from global list. See the comment in breakpoint.c: if (remove_breakpoint (old_loc, mark_uninserted)) { /* This is just about all we can do. We could keep this location on the global list, and try to remove it next time, but there's no particular reason why we will succeed next time. Note that at this point, old_loc->owner is still valid, as delete_breakpoint frees the breakpoint only after calling us. */ printf_filtered (_("warning: Error removing " "breakpoint %d\n"), old_loc->owner->number); } If we change the policy to "keep breakpoint instances if fail to remove from inferior", this problem may be fixed. > 2. If inferior is stoped by this breakpoint, adjust_pc_after_break > didn't know this stop is beauce the breakpoint, so the pc address will > not be adjust to the right value. adjust_pc_after_break doesn't know because there is no breakpoint instance in GDB. -- Yao (齐尧)