From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20898 invoked by alias); 7 Sep 2007 20:11:28 -0000 Received: (qmail 20887 invoked by uid 22791); 7 Sep 2007 20:11:27 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 07 Sep 2007 20:11:23 +0000 Received: (qmail 20286 invoked from network); 7 Sep 2007 20:11:20 -0000 Received: from unknown (HELO h38.net64.aknet.ru) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 7 Sep 2007 20:11:20 -0000 From: Vladimir Prus To: gdb-patches@sources.redhat.com Subject: [0/9] Breakpoints at multiple locations Date: Fri, 07 Sep 2007 20:11:00 -0000 User-Agent: KMail/1.9.6 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709080011.13700.vladimir@codesourcery.com> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-09/txt/msg00088.txt.bz2 At the moment, gdb assumes that a code breakpoint has a single PC value. One case where it does not work is C++ constructors -- GCC generates several function bodies, and GDB sets breakpoint on just one of them, so breakpoints in constructors don't work reliably. Another case is C++ templates -- if I set a breakpoint on a line in template function, there's unbounded number of template instantiations that have this line, but GDB cannot set breakpoints on all of them. I'm about to post a set of patches that fix it. Essentially, the patches make breakpoint have a list of breakpoint locations. When a breakpoint is creates, GDB automatically figures out the set of locations to use. User can than disable locations that seem uninteresting to him. GDB can also handle locations in shared libraries. Suppose you have breakpoint at foo.hpp:10, which is a template function. Then, when new shared library is loaded, gdb will figure out if there is any code in the library corresponding to foo.hpp:4. If now, the list of locations for the breakpoint will be updated. As a side effect, this set of patches simplifies internal handling of pending breakpoints. Since we need the code to recompute all locations when a shared library is loaded, there's no need to special-case pending breakpoints, so now pending breakpoint is a breakpoint without any locations. Importantly, when pending breakpoint is resolved, it no longer gets a new number, which should make MI frontends a little bit happier. The patches has direct effect on two user commands. The "info break" now outputs multiple locations, if they are present, like this: Num Type Disp Enb Address What 1 breakpoint keep y 1.1 y 0xb7fa756d in int bar(int) at helper.hpp:4 1.2 y 0xb7fa7588 in double bar(double) at helper.hpp:4 The output for a breakpoint with single location is not changed. The display of pending breakpoints is improved. In CVS HEAD as it is now, breakpoint internally has three important states: - enabled - disabled - shlib_disabled Breakpoint enters the last state when the library it is in is unloaded. User can never explicitly specify this state. Unfortunately, user can explicitly leave this state, using the 'enable' command. The result will be an error on next resume -- as gdb will try to insert this breakpoint, in an unloaded library. My patches explicitly separate "enabled/disabled" state, which can be changed by user, and the "pending" state -- which means that this breakpoint is not in a loaded code yet, and won't fire yet. The pending state is maintained by gdb. The display is adjusted accordingly -- for pending breakpoints we show "(p)" after "y" or "n", for example: 1 breakpoint keep y breakpoint already hit 2 times 1.1 y(p) 0xb7f9856d helper.hpp:4 1.2 n(p) 0xb7f98588 helper.hpp:4 means that user wants location 1.1 to be enabled, and wants location 1.2 to be disabled. The "(p)" means that both are in unloaded shared library, so naturally 1.1 won't be hit until the library is loaded. In addition to "info break" changes, the "enable" and "disable" commands were modified to accept locations, so: disable 1.2 will disable second location of breakpoint 1. Since the original patch was about 100K and non-intelligible, it was split in 9 separate patches. Each leaves gdb without regressions and some patches have a value on their own. 1. Remove stale code in update_breakpoints_after_exec 2. Remove the 'silent' parameter in disable_breakpoints_in_shlibs. 3. Introduce bpstat_free 4. Change bpstat->breakpoint_at to point at bp_location. 5. Move the 'cond' field from breakpoint to bp_location. 6. Extract some code into separate functions 7. Handle pending breakpoints in breakpoint_re_set_one 8. Allow breakpoint to have multiple locations. 9. Create multiple locations for breakpoints in constructors and template functions Patches 1-3 are rather trivial, and already committed. The remaining patches were already reviewed by Jim Blandy, and revised, and re-reviewed several times, and are actually all approved now. However, breakpoint.c is scary, and the patches are big, so I'll appreciate all possible review. If I don't get any objections within 2 weeks, I'm gonna commit those patches as is. - Volodya