From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16658 invoked by alias); 18 Feb 2003 20:42:10 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 16651 invoked from network); 18 Feb 2003 20:42:10 -0000 Received: from unknown (HELO mx1.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 18 Feb 2003 20:42:10 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h1IKgAK00401 for ; Tue, 18 Feb 2003 15:42:10 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h1IKg9a10662; Tue, 18 Feb 2003 15:42:09 -0500 Received: from localhost.localdomain (vpn50-1.rdu.redhat.com [172.16.50.1]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h1IKg9525803; Tue, 18 Feb 2003 15:42:09 -0500 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id h1IKg3v04651; Tue, 18 Feb 2003 13:42:03 -0700 Date: Tue, 18 Feb 2003 20:42:00 -0000 From: Kevin Buettner Message-Id: <1030218204203.ZM4650@localhost.localdomain> In-Reply-To: Daniel Jacobowitz "Re: Is stub support for the 's' packet optional or required?" (Feb 18, 3:23pm) References: <20030218020408.EE11C3CF2@localhost.redhat.com> <1030218162957.ZM3642@localhost.localdomain> <20030218165140.GA17229@nevyn.them.org> <1030218200628.ZM4508@localhost.localdomain> <20030218202328.GA32467@nevyn.them.org> To: Daniel Jacobowitz , Kevin Buettner Subject: Re: Is stub support for the 's' packet optional or required? Cc: gdb@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-02/txt/msg00319.txt.bz2 On Feb 18, 3:23pm, Daniel Jacobowitz wrote: > That's a bug in software single step handling; I bet it shows up now > too, just less often (because of latency changes). I think it's as > simple as marking the single-step breakpoint thread-specific in the > normal way, but it might be a little more complicated... One of the problems with the single-step breakpoint machinery is that it doesn't use the mechanisms in breakpoint.c, so it can't be marked in the normal way (or in any way). I'm presently looking at introducing a new breakpoint type for software single step. Once that's done, I'm hoping that we can do as you suggest without having to move the location of the SOFTWARE_SINGLE_STEP invocations. The location of the invocations of SOFTWARE_SINGLE_STEP() may make this hard to do though. It is invoked to insert its breakpoint long after breakpoints have been inserted. Likewise, when removing breakpoints, this happens much earlier than normal breakpoints are removed. Kevin