From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3033 invoked by alias); 11 Mar 2003 15:13:35 -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 3026 invoked from network); 11 Mar 2003 15:13:35 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by 172.16.49.205 with SMTP; 11 Mar 2003 15:13:35 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 1687D2A9C for ; Tue, 11 Mar 2003 10:13:34 -0500 (EST) Message-ID: <3E6DFD1D.4090205@redhat.com> Date: Tue, 11 Mar 2003 15:13:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gdb@sources.redhat.com Subject: fix break, not add future-break Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-03/txt/msg00158.txt.bz2 Hello, There is a change kicking around that adds a new `future-break' command. It started life as `save breakpoints': http://sources.redhat.com/ml/gdb-patches/2001-12/msg00108.html that received a prompt review response. Unfortunatly, instead of simply addressing the relevant issues, it turned into a future-break jumbo patch: http://sources.redhat.com/ml/gdb-patches/2001-12/msg00296.html At the time Tom Tromey made the point: > Klee> The 'future-break' command allows one to specify a breakpoint > Klee> that starts off as 'shlib_disabled' instead of generating an > Klee> error if it can't be set immediately. > > Klee> I'm not entirely happy with the future-break command, and > Klee> particularly with its interaction with the save-breakpoints > Klee> mechanism (if you set a breakpoint that is in a shared library > Klee> after shared libraries have been loaded, you have to remember to > Klee> use the future-break command, not the break command). > > Doesn't this mean that programs like Insight would be best advised to > *only* set future breakpoints? In that case let's just add the > functionality directly to the existing breakpoint commands. http://sources.redhat.com/ml/gdb-patches/2001-12/msg00152.html (the original contributor never responded.) I think Tom is right. Rather than adding a new contextually sensitive command (`don't mode me in'), GDB should `fix' the existing break command. Just like the GUI, normal users are going to be confused by this unnecessary choice. Why, after all, should a user have to learn a different command just so that they can set breakpoints on an unloaded shared library? Further, if GUI implementors want specific break command semantics, then they should be extending the MI interface and not perverting the CLI. I'd like to propose that break be modified so that it behaves something like: (gdb) break printf.c:printf File "printf.c" not currently known, set breakpoint anyway? And then later: (gdb) c Loading shared library libc.so. Enabling breakpoint "printf.c:printf" at .... For edge conditions: - If the executable is re-started or re-loaded, all breakpoints get marked as `unloaded' (or what ever shlib breakpoints are ment to get set to) and then get enabled as they become valid. - If it turns out that a breakpoint is never enabled then `oops'. - If it turns out that a breakpoint wasn't valid, issue a warning and disable it for the remainder of that session (?). - If a breakpoint isn't valid in a script, then issue a warning and add it anyway. Who's it going to hurt? - if the executable being debugged is changed then, well, do what ever the current code does. Andrew