From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12526 invoked by alias); 14 Oct 2005 19:38:55 -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 12444 invoked by uid 22791); 14 Oct 2005 19:38:50 -0000 Received: from s142-179-108-108.bc.hsia.telus.net (HELO takamaka.act-europe.fr) (142.179.108.108) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 14 Oct 2005 19:38:50 +0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 94BD247E79; Fri, 14 Oct 2005 12:38:48 -0700 (PDT) Date: Fri, 14 Oct 2005 19:38:00 -0000 From: Joel Brobecker To: gdb@sources.redhat.com Subject: Re: New command to save breakpoints? Message-ID: <20051014193848.GO959@adacore.com> References: <20051011174255.GB1015@adacore.com> <20051014154434.GB28117@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051014154434.GB28117@nevyn.them.org> User-Agent: Mutt/1.4i X-SW-Source: 2005-10/txt/msg00088.txt.bz2 > > . 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? I agree. This means we need to temporarily force "... pending" to off and restore it later. I don't know of any way of doing this using GDB's scripting language, so we're leaning towards the counter-part of the save-breakpoints command, a new command that also restores them? So the design at the user-interface level would become something like this (the command names can also be debated of course): . new command: ``save-breakpoints'' stores breakpoints in script format (design unchanged) . new command: ``restore-breakpoints'' saves the current breakpoint-pending status sources the script restores the breakpoint-pending status > > . 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. That's my feeling too. At the implementation level, however, this causes an extra difficulty as simple sourcing of the script will abort if such error happens. So we'll need to find a solution (such as diverting all errors during the sourcing and transform them into warnings, or implement a switch to the break command to report what normally are errors as warnings). Or we can decide no use to a normal source, but something else. To be determined. > 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. That's a very good point. > - what if a breakpoint location is still valid, but the conditional > check no longer parses there? Not sure what is best to do in this case. It could be argued both ways, really. Perhaps the most sensible thing to do is to insert the breakpoint without the condition, and print a warning to the user. If we agree that reloading saved breakpoints and resetting brekpoints should use the same behavior/code, then we can discuss the problems of the current GDB separately (I prefer breaking down problems in smaller ones). -- Joel