From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14083 invoked by alias); 4 Nov 2002 20:44:08 -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 14076 invoked from network); 4 Nov 2002 20:44:07 -0000 Received: from unknown (HELO zenia.red-bean.com) (66.244.67.22) by sources.redhat.com with SMTP; 4 Nov 2002 20:44:07 -0000 Received: (from jimb@localhost) by zenia.red-bean.com (8.11.6/8.11.6) id gA4KTNT17756; Mon, 4 Nov 2002 15:29:23 -0500 To: Andrew Cagney Cc: "Howell, David P" , Daniel Jacobowitz , wim delvaux , gdb@sources.redhat.com Subject: Re: why is gdb 5.2 so slow References: <331AD7BED1579543AD146F5A1A44D5251279CE@fmsmsx403.fm.intel.com> <3DC2E819.9000700@redhat.com> From: Jim Blandy Date: Mon, 04 Nov 2002 12:44:00 -0000 In-Reply-To: <3DC2E819.9000700@redhat.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.90 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-11/txt/msg00043.txt.bz2 Andrew Cagney writes: > 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. I've heard it suggested that, for this behavior, the kernel shouldn't know about breakpoints specifically, since those need all sorts of other support (GDB has to be ptracing and waiting, etc.). Instead, the kernel would provide some way for a debugger to make some memory writes (e.g., breakpoints) --- but not others (e.g., variable modifications) --- via a special interface that would revert the writes when the GDB process exited or died. The ways I can think of to implement this involve page table magic, which makes me wonder if one couldn't actually use them for per-thread breakpoints and thread hops, too. That is, if the debugger could make one thread see the program text differently from the others, then it could pull the breakpoint for that thread alone, while leaving it in for the others. No thread hop necessary. I'm of out my depth here, though --- I've never looked at Linux's mm layer, for example, and don't understand its limitations. Just an idea.