From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28460 invoked by alias); 5 Dec 2001 05:11:13 -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 28101 invoked from network); 5 Dec 2001 05:09:48 -0000 Received: from unknown (HELO dc-mx05.cluster1.charter.net) (209.225.8.15) by sources.redhat.com with SMTP; 5 Dec 2001 05:09:48 -0000 Received: from [24.241.47.50] (HELO localhost) by dc-mx05.cluster1.charter.net (CommuniGate Pro SMTP 3.4.6) with ESMTP id 2797229; Wed, 05 Dec 2001 00:15:03 -0500 Received: from kdienes by localhost with local (Exim 3.32 #1 (Debian)) id 16BUJM-0003ml-00; Wed, 05 Dec 2001 00:09:36 -0500 From: Klee Dienes Reply-To: Klee Dienes To: Michael Snyder Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC] add 'save-breakpoints' command References: <3C0D520C.E9016E83@cygnus.com> Date: Tue, 04 Dec 2001 21:11:00 -0000 In-Reply-To: <3C0D520C.E9016E83@cygnus.com> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2001-12/txt/msg00122.txt.bz2 > Could you elaborate a little bit on how this change works with > shlib breakpoints, what the original_type field is for, the > bp_tbreakpoint type, etc.? In what circumstances is the > current breakpoint type different from the original breakpoint type? The original_type field is for cases like 'tbreak' or 'thbreak' where the bp_type gets set simply to 'breakpoint', but we nonethless want the proper command to be written to the generated file. In these cases we just set the original_type field to the appropriate value, and use that when writing out the command to the file. It's also used for non-used specified breakpoints --- in these cases the value is set to 'bp_none', to indicate that it should not be written to the file. > There are several mentions of future breaks; you should probably > clean those up until you're ready to submit that feature. Actually, upon further reflection, I should probably combine the two diffs and submit them as one patch. Let me look into how well that works out and post a new diff tomorrow. > get_breakpoint_count is defined but never used. Whoops. That's just a function needed by another of our patches that somehow managed to sneak in. I'll remove it for now.