From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9945 invoked by alias); 4 Dec 2001 18:44:12 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 9902 invoked from network); 4 Dec 2001 18:44:06 -0000 Received: from unknown (HELO dc-mx01.cluster1.charter.net) (209.225.8.11) by sources.redhat.com with SMTP; 4 Dec 2001 18:44:06 -0000 Received: from [24.241.47.50] (HELO localhost) by dc-mx01.cluster1.charter.net (CommuniGate Pro SMTP 3.4.6) with ESMTP id 50348704; Tue, 04 Dec 2001 13:51:40 -0500 Received: from localhost ([127.0.0.1] helo=salmon.localnet) by localhost with esmtp (Exim 3.32 #1 (Debian)) id 16BKXp-0002Xy-00; Tue, 04 Dec 2001 13:43:53 -0500 From: Klee Dienes Reply-To: Klee Dienes To: Daniel Jacobowitz cc: Klee Dienes , gdb-patches@sources.redhat.com Subject: Re: [RFC] add 'save-breakpoints' command In-Reply-To: Your message of "Tue, 04 Dec 2001 13:27:21 EST." <20011204132721.A11047@nevyn.them.org> References: <20011204132721.A11047@nevyn.them.org> Date: Tue, 04 Dec 2001 10:44:00 -0000 Message-Id: X-SW-Source: 2001-12/txt/msg00111.txt.bz2 The way we addressed this in our sources was to add a new 'future-break' command, and modify the way we handle breakpoints that cannot be inserted. When our GDB is unable to set a breakpoint that has previously been set successfuly, it marks the breakpoint as 'shlib_disabled'. Then when shared libraries are loaded, GDB goes through the list of shlib_disabled breakpoints and tries to re-set them. The 'future-break' command allows one to specify a breakpoint that starts off as 'shlib_disabled' instead of generating an error if it can't be set immediately. I'm not entirely happy with the future-break command, and particularly with its interaction with the save-breakpoints mechanism (if you set a breakpoint that is in a shared library after shared libraries have been loaded, you have to remember to use the future-break command, not the break command). This isn't a particularly big problem for us, since we do decent good job of pre-loading symbols for all our shared libraries --- but it's enough that I thought it better to treat as a separate issue from the save-breakpoints command.