From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28156 invoked by alias); 10 Sep 2007 15:38:34 -0000 Received: (qmail 28148 invoked by uid 22791); 10 Sep 2007 15:38:34 -0000 X-Spam-Check-By: sourceware.org Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 10 Sep 2007 15:38:30 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1IUlLG-0008C0-Ih for gdb-patches@sources.redhat.com; Mon, 10 Sep 2007 19:38:26 +0400 Received: from localhost ([127.0.0.1] helo=ip6-localhost) by zigzag.lvk.cs.msu.su with esmtp (Exim 4.50) id 1IUlLB-0008Bp-1C; Mon, 10 Sep 2007 19:38:21 +0400 From: Vladimir Prus Subject: Re: [0/9] Breakpoints at multiple locations To: Markus Deuling , gdb-patches@sources.redhat.com Date: Mon, 10 Sep 2007 15:38:00 -0000 References: <200709080011.13700.vladimir@codesourcery.com> <200709081831.47826.vladimir@codesourcery.com> <46E4CC11.8050502@de.ibm.com> <200709101207.17128.vladimir@codesourcery.com> <46E5501E.9080205@de.ibm.com> User-Agent: KNode/0.10.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit Message-Id: 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/msg00137.txt.bz2 Markus Deuling wrote: > >>> Vladimir Prus schrieb: >>>> Once the library is unloaded, we get: >>>> >>>> Num Type Disp Enb Address What >>>> 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 >>> Just an idea but for my opinion it would be great to have a hit-counter >>> per location like: >>> >>> Num Type Disp Hit Enb Address What >>> 1 breakpoint keep 8 y >>> 1.1 5 y(p) 0xb7f9856d helper.hpp:4 >>> 1.2 3 n(p) 0xb7f98588 helper.hpp:4 >>> >>> The entity could add up the counts of all locations. This >>> would also get rid of the annoying "breakpoint already hit xy times" >>> line :-) >>> >>> What do you think? >> >> That can possibly be interesting, but how will you handle 'ignore' >> count then? Should it be per-location, too? >> >> I actually don't think those patches are final -- I expect some UI tweaks >> to be made when this feature is more used. > > Hm, after a very-quick-look through breakpoint.c I see no problem in > moving both ignore_count and hit_count to per-location. I guess it would > make sense to let these two together and have them in a per-location way. > This reflects reality best. GDB may want to set different ignore counts to > different breakpoint locations and count how often a specific location was > hit. There's no technical problem doing that. However, I'm not quite sure if this is good idea in general, and I even less sure what MI frontends might want to do. Recall that now, I operates in kind of compatibility mode -- it does not list breakpoint locations at all. So if we change to per-location hit/ignore, we need to think how to not break MI frontends, and we should think how future MI version will handle all this. > > Maybe thats something to come up with after the initial patch set for your > multiple location breakpoints are committed. Definitely, maintaining this all locally is too much work, so tweaking interface is better done separately. - Volodya