From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18044 invoked by alias); 8 Feb 2007 13:00:19 -0000 Received: (qmail 18026 invoked by uid 22791); 8 Feb 2007 13:00:15 -0000 X-Spam-Check-By: sourceware.org Received: from inet-tsb5.toshiba.co.jp (HELO inet-tsb5.toshiba.co.jp) (202.33.96.24) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 08 Feb 2007 12:59:51 +0000 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb5.toshiba.co.jp with ESMTP id l18CxkWI022857 for ; Thu, 8 Feb 2007 21:59:46 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id l18Cxld1006556 for gdb-patches@sourceware.org; Thu, 8 Feb 2007 21:59:47 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with ESMTP id XAA06555; Thu, 8 Feb 2007 21:59:47 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id l18CxkSa023491 for ; Thu, 8 Feb 2007 21:59:46 +0900 (JST) Received: from mx.tjsys.co.jp by toshiba.co.jp id l18CxkSU028260; Thu, 8 Feb 2007 21:59:46 +0900 (JST) Received: from is-com10 (IDENT:U2FsdGVkX1/B5Kn6jhtDb3tzZfZnbcP5xVSigx5zNBw@filtering.tjsys.co.jp [157.79.3.71]) by mx.tjsys.co.jp (8.12.11/8.12.11) with SMTP id l18CxkNl008952 for ; Thu, 8 Feb 2007 21:59:46 +0900 (JST) Received: from localhost ([157.79.51.133]) by ims.tjsys.co.jp (iPlanet Messaging Server 5.2 HotFix 2.10 (built Dec 26 2005)) with ESMTP id <0JD500KY1ARH3J@ims.tjsys.co.jp> for gdb-patches@sourceware.org; Thu, 08 Feb 2007 21:59:41 +0900 (JST) Date: Thu, 08 Feb 2007 13:00:00 -0000 From: Emi SUZUKI Subject: Re: [patch] "single step" atomic instruction sequences as a whole. In-reply-to: <200702071110.01767.luisgpm@br.ibm.com> To: gdb-patches@sourceware.org Message-id: <20070208.215940.115903865.emi-suzuki@tjsys.co.jp> MIME-version: 1.0 X-Mailer: Mew version 5.2 on Emacs 22.0.91 / Mule 5.0 (SAKAKI) Content-type: Text/Plain; charset=us-ascii Content-transfer-encoding: 7bit References: <200702060902.25196.luisgpm@linux.ibm.com> <20070206.211127.71089279.emi-suzuki@tjsys.co.jp> <200702071110.01767.luisgpm@br.ibm.com> X-WAuditID: 0702082159410000019246 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: 2007-02/txt/msg00068.txt.bz2 Hello Luis, Thank you for your reply. * On Wed, 07 Feb 2007 11:10:01 -0200, Luis Machado wrote: > What's exactly been modified on your patch for single stepping of atomic > instruction sequences? OK, I will explain about them one by one. First, I defined the entity of SOFTWARE_SINGLE_STEP_P macro on rs6000-tdep.c. It returns true if the new function 'rs6000_deal_with_atomic_sequence' returns a non-zero value, say, skipping an atomic sequence instruction is needed. 'rs6000_deal_with_atomic_sequence' is derived from Paul's patch to search the subsequent instructions: it start reading instructions from PC and returns the address which indicates the end of the atomic sequence if any is found. It is also called by 'rs6000_software_single_step' to get the address to which a software single-step breakpoint will be set. 'rs6000_software_single_step' is set to gdbarch by 'set_gdbarch_software_single_step'. Note that the gdbarch definition for RS6000 is also used when GDB was configured for the POWER architectures, so the modification also effects on ppc*-linux configuration without defining in ppc-linux-tdep.c. # I didn't see any differences between the patchs for those two files # which you have resent, but point me out if I have missed something. By the changes above, GDB sometimes makes the target do software single-stepping even if the target environment supports hardware single-stepping: the basic behavior is the same as what Paul's patchset does. But the function handle_inferior_event, defined in infrun.c, has some codes based on the assumption that the status of hardware single-stepping support is not changed during the debugging session. So I removed these codes. And the thread hopping procedures should be done when the thread other than the one doing software single-stepping runs on a stop-code for software single-stepping. It can also occur while "temporary software single-stepping" is being done, but handle_inferior_event doesn't take those things into consideration. So I added the code to save 'singlestep_ptid' in resume, even when a hardware single-stepping will be done. It will be compared with the ptid of the trapped thread for checking if the thread hopping occured. > Does it handle the issues that you have mentioned > about thread hopping check? It should do, logically. But I have checked only on our hardware. I will appreciate if you check it on your environment. Maybe I should write a test code for testsuite... Best regards, -- Emi SUZUKI