From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27067 invoked by alias); 8 Sep 2007 11:57:52 -0000 Received: (qmail 27059 invoked by uid 22791); 8 Sep 2007 11:57:52 -0000 X-Spam-Check-By: sourceware.org Received: from romy.inter.net.il (HELO romy.inter.net.il) (213.8.233.24) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 08 Sep 2007 11:57:47 +0000 Received: from HOME-C4E4A596F7 (IGLD-80-230-141-251.inter.net.il [80.230.141.251]) by romy.inter.net.il (MOS 3.7.3-GA) with ESMTP id IVN48672 (AUTH halo1); Sat, 8 Sep 2007 14:57:36 +0300 (IDT) Date: Sat, 08 Sep 2007 11:57:00 -0000 Message-Id: From: Eli Zaretskii To: Vladimir Prus CC: gdb-patches@sources.redhat.com In-reply-to: <200709080011.13700.vladimir@codesourcery.com> (message from Vladimir Prus on Sat, 8 Sep 2007 00:11:13 +0400) Subject: Re: [0/9] Breakpoints at multiple locations Reply-to: Eli Zaretskii References: <200709080011.13700.vladimir@codesourcery.com> X-IsSubscribed: yes 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/msg00114.txt.bz2 > From: Vladimir Prus > Date: Sat, 8 Sep 2007 00:11:13 +0400 > > 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. Thanks, this is a great feature to have in GDB. I hope there will be a suitable patch for the user manual, before all this is committed. I tried to indicate what new features need to be reflected in the manual, when I saw them in your patches (but I'm not sure I saw all of them). Also, I think this features should be mentioned in NEWS. > 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 As I wrote in one of my messages, the "1.2" thing could potentially break alignment of the display. I think we should handle that somehow. Also, I'm not convinced that 1.2 is the best possible way to express what you want, because it looks like a floating-point number. Maybe we should explicitly have an additional "Loc" column, and format the list like this: Num Loc 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 > 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. I think the old was much more clear than this enigmatic "(p)". Thanks again for working on this.