From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20404 invoked by alias); 1 Nov 2002 20:46:22 -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 20321 invoked from network); 1 Nov 2002 20:46:21 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 1 Nov 2002 20:46:21 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 307603CB1; Fri, 1 Nov 2002 15:46:18 -0500 (EST) Message-ID: <3DC2E819.9000700@redhat.com> Date: Fri, 01 Nov 2002 12:46:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020824 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Howell, David P" Cc: Daniel Jacobowitz , wim delvaux , gdb@sources.redhat.com Subject: Re: why is gdb 5.2 so slow References: <331AD7BED1579543AD146F5A1A44D5251279CE@fmsmsx403.fm.intel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-11/txt/msg00013.txt.bz2 >> - Removing all breakpoints, that's just wrong, there's a test in >> signals.exp (xfailed :P) which shows why. We should _only_ be > > removing > >> any breakpoints at the address we're hopping over. > > [DPH] I thought we need this to show a clean program space, i.e. without > > gdb's modifications, i.e. breakpoints. My guess is that the code > is > general that does this and we'd have to put more logic in to > detect > when we are poking in the address space after the breakpoint. No. Breakpoints are pulled to ensure that the target is clean when [not if :-)] gdb barfs / is killed / .... Attach GDB to a process, set a few breakpoints, continue the process, and then shoot GDB. The process quickly dies with a SIGTRAP from one of those, still in memory, breakpoints. GDB does have methods that present a clean program space. Using those functions, and not pulling breakpoints, should largely involve legwork. However, things like single-step and thread-hop would be more complicated involving a bit of think-o to get right. What would really help is for the kernel to provide an option where it rips out out any stray breakpoints after a detach. That way GDB could safely enable this by default. Andrew