From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11316 invoked by alias); 14 Oct 2005 15:44:41 -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 10943 invoked by uid 22791); 14 Oct 2005 15:44:37 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 14 Oct 2005 15:44:37 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1EQRjW-0007Qf-PK; Fri, 14 Oct 2005 11:44:34 -0400 Date: Fri, 14 Oct 2005 15:44:00 -0000 From: Daniel Jacobowitz To: Joel Brobecker Cc: gdb@sources.redhat.com Subject: Re: New command to save breakpoints? Message-ID: <20051014154434.GB28117@nevyn.them.org> Mail-Followup-To: Joel Brobecker , gdb@sources.redhat.com References: <20051011174255.GB1015@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051011174255.GB1015@adacore.com> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-10/txt/msg00087.txt.bz2 On Tue, Oct 11, 2005 at 10:42:55AM -0700, Joel Brobecker wrote: > Hello, > > some of our customers have asked us to enhance the debugger to be able > to save breakpoints in a file, in order to reset them later. We feel > it's a useful functionality to have and share with the rest of the > GDB community. > > Within AdaCore, we have adopted the interface that Apple has implemented > in their own version of the debugger. So they added a command called > "save-breakpoint" which will generate a set of GDB commands re-creating > each breakpoint. To reset the breakpoints, one just "source"s this > file. I like thie idea, with caveats. > I personally like the simplicity of this approach. There are a few > issues we need to discuss, however: More than just these... > . What happens if one of the breakpoints is inside a shared library > and that the symbols for the library haven't been loaded yet? > The current result depends on the "breakpoint pending" setting. Pending breakpoints should be forced on while loading the saved breakpoints file, surely? > . What happens if one of the breakpoints locations is OBE and > leads to an error? Again, depending on the "breakpoint pending" > setting, the script will either set a pending breakpoint, ignore > silently, or abort. The closest matches I can find are "out of body experience" and "oracle by example". I'm going to assume that you want something sort of like the former... It should warn and ignore, presumably. Reloading saved breakpoints is, fundamentally, the same problem as resetting breakpoints after reloading an executable or shared library. We need the same information and it would be nice to commonize the two a bit better. Here's some other hangups I remember from when I looked at the latter problem last: - there's at least one reference to the "current" language when setting breakpoints; if your application is C++ and the startup code has debug info tagging it as C or assembly, this can break down badly. - what if a breakpoint location is still valid, but the conditional check no longer parses there? I think there's more, but I can't remember what they might have been. So maybe not. -- Daniel Jacobowitz CodeSourcery, LLC