From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26437 invoked by alias); 10 Apr 2007 08:38:33 -0000 Received: (qmail 26421 invoked by uid 22791); 10 Apr 2007 08:38:32 -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; Tue, 10 Apr 2007 09:38:30 +0100 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb5.toshiba.co.jp with ESMTP id l3A8NF2V013247; Tue, 10 Apr 2007 17:23:15 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id l3A8NGLt026314; Tue, 10 Apr 2007 17:23:16 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with ESMTP id TAA26312; Tue, 10 Apr 2007 17:23:16 +0900 Received: from mx11.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id l3A8NFA5009634; Tue, 10 Apr 2007 17:23:15 +0900 (JST) Received: from mx.tjsys.co.jp by toshiba.co.jp id l3A8NEW6007847; Tue, 10 Apr 2007 17:23:15 +0900 (JST) Received: from is-com10 (IDENT:U2FsdGVkX1/5rFszrF1qAu3viiBmRKo07PZhiuLgRyM@filtering.tjsys.co.jp [157.79.3.71]) by mx.tjsys.co.jp (8.12.11/8.12.11) with SMTP id l3A8NEiG027157; Tue, 10 Apr 2007 17:23:14 +0900 (JST) Received: from localhost ([157.79.51.145]) by ims.tjsys.co.jp (iPlanet Messaging Server 5.2 HotFix 2.10 (built Dec 26 2005)) with ESMTP id <0JG90090QWMOHZ@ims.tjsys.co.jp>; Tue, 10 Apr 2007 17:23:13 +0900 (JST) Date: Tue, 10 Apr 2007 08:38:00 -0000 From: Emi SUZUKI Subject: Re: single-stepping and internal breakpoints on a multi-threaded program In-reply-to: <1175898309.11945.72.camel@svmsnyderlnx.palmsource.com> To: Michael.Snyder@access-company.com Cc: jimb@codesourcery.com, gdb@sourceware.org Message-id: <20070410.172318.01365391.emi-suzuki@tjsys.co.jp> MIME-version: 1.0 X-Mailer: Mew version 5.2 on Emacs 22.0.90 / Mule 5.0 (SAKAKI) Content-type: Text/Plain; charset=us-ascii Content-transfer-encoding: 7bit References: <20070405.205731.12335149.emi-suzuki@tjsys.co.jp> <1175898309.11945.72.camel@svmsnyderlnx.palmsource.com> X-WAuditID: 0704101723130000016639 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-04/txt/msg00049.txt.bz2 Jim and Michael, Thank you for your comments. From: Michael Snyder Subject: Re: single-stepping and internal breakpoints on a multi-threaded program Date: Fri, 06 Apr 2007 15:25:09 -0700 > > I have forgetten exactly how GDB handles multi-threaded single > > stepping; I'm afraid I can't suggest how to do this. If you're unable > > to fix it yourself, please file a bug report, and include your test > > program. > > I'm thinking that gdb just loses the "I'm stepping this thread" > bit of state info, which is normally handled in "proceed" and > stored in the infrun-state struct - whereupon it just continues > both threads without stepping. I think it's true in some ways: it seemed that the clue for GDB to decide that "I'm stepping this thread" is eventually only the value of step_range_end. When the target get stopped on a thread different from which GDB expected to stop, it was preserved in the thread_info structure by context_switch, but never had an oppotunity to be looked back till the target get stopped on that thread again. It is not just lost, but no better than lost. I think I should work more on the problem, but unfortunately, my copyright assignment to FSF is still not ready. So I will file it to the bug tracking system, following Jim's advice. I will be back on it when I find that anything is not done for it after my assignment is ready. I hope not, though :-) Thanks anyway, -- Emi SUZUKI