From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26744 invoked by alias); 19 Aug 2008 06:10:35 -0000 Received: (qmail 26735 invoked by uid 22791); 19 Aug 2008 06:10:34 -0000 X-Spam-Check-By: sourceware.org Received: from imx12.toshiba.co.jp (HELO imx12.toshiba.co.jp) (61.202.160.132) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 19 Aug 2008 06:09:28 +0000 Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id m7J69Evk001423; Tue, 19 Aug 2008 15:09:14 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id m7J69E0X020045; Tue, 19 Aug 2008 15:09:14 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id RAA20044; Tue, 19 Aug 2008 15:09:14 +0900 Received: from mx12.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id m7J69DQM022882; Tue, 19 Aug 2008 15:09:14 +0900 (JST) Received: from mx.tjsys.co.jp by toshiba.co.jp id m7J69Ddc029997; Tue, 19 Aug 2008 15:09:13 +0900 (JST) Received: from voltage-out.tjsys.co.jp (voltage-out.tjsys.co.jp [157.79.3.51]) by mx.tjsys.co.jp (8.12.11/8.12.11) with ESMTP id m7J69Da4025078; Tue, 19 Aug 2008 15:09:13 +0900 (JST) Received: from is-com10 ([157.79.3.71]) by voltage-out.tjsys.co.jp (8.13.1/8.13.1) with SMTP id m7J698rr013861; Tue, 19 Aug 2008 15:09:08 +0900 Received: from localhost ([157.79.30.231]) by ims.tjsys.co.jp (iPlanet Messaging Server 5.2 HotFix 2.10 (built Dec 26 2005)) with ESMTP id <0K5U00EGS3R5GY@ims.tjsys.co.jp>; Tue, 19 Aug 2008 15:09:05 +0900 (JST) Date: Tue, 19 Aug 2008 06:10:00 -0000 From: SUZUKI Emi Subject: Re: [RFA] thread specific breakpoints and single stepping In-reply-to: <20080801.205849.190217198.emi-suzuki@tjsys.co.jp> To: drow@false.org Cc: pedro@codesourcery.com, gdb-patches@sourceware.org Message-id: <20080819.150914.01383883.emi-suzuki@tjsys.co.jp> MIME-version: 1.0 X-Mailer: Mew version 6.1 on Emacs 22.1 / Mule 5.0 (SAKAKI) Content-type: Text/Plain; charset=us-ascii Content-transfer-encoding: 7bit References: <20080709.211038.135588294.emi-suzuki@tjsys.co.jp> <20080726030133.GC1895@caradoc.them.org> <20080801.205849.190217198.emi-suzuki@tjsys.co.jp> X-WAuditID: 0808191509050000015975 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: 2008-08/txt/msg00511.txt.bz2 Ping? Or, should I offer reviews separately, with deleting the call of breakpoint_thread_match and calling single_step_breakpoint_inserted_here_p? From: Emi SUZUKI Subject: Re: [RFA] thread specific breakpoints and single stepping Date: Fri, 01 Aug 2008 20:58:49 +0900 (JST) > Hi Daniel, > > thank you for your comment. > > From: Daniel Jacobowitz > Subject: Re: [RFA] thread specific breakpoints and single stepping > Date: Fri, 25 Jul 2008 23:01:33 -0400 > > > On Wed, Jul 09, 2008 at 09:10:38PM +0900, Emi SUZUKI wrote: > > > It works better than mine. But while I am concerning about > > > single-stepping for software watchpoints, I noticed that we should > > > also check whether a hardware watchpoint is triggered. > > > > As this condition gets more complicated, I'm getting worried about > > keeping it in sync with everything else. Could it be that the logic > > is wrong - we should determine whether a thread hop is necessary later > > in the process? It should be just like a breakpoint with a false > > condition. > > Ah, yes. I also feel like that I would eventually implement the same > procedures to two different places... > > I investigated the condition again, and found that all the need for > thread hopping over a regular breakpoint can determine by calling > bpstat_stop_status as you suggested: even breakpoint_thread_match is > not necessary here. > So I revised the patch to delete it. handle_inferior_event was the > last caller of breakpoint_thread_match, but I just left it defined. > > And I found another problem: when a hardware watchpoint trigger > occured while doing software single-stepping, the trigger can be > ignored by a thread hop. > > I think it would be fixed by calling > single_step_breakpoint_inserted_here_p instead of checking > singlestep_breakpoints_inserted_p, to make sure a thread is really > trapped by a software single step breakpoint. But I don't have a > environment where I can reproduce the situation. > It may occur on a PPC box...? > > And I doubt if the testcases are reasonable now, but at least the > tests fails without a patch, and succeeds with it, on x86-linux-gnu. > > Is that OK?