From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29168 invoked by alias); 27 Apr 2011 18:02:01 -0000 Received: (qmail 29141 invoked by uid 22791); 27 Apr 2011 18:01:59 -0000 X-SWARE-Spam-Status: No, hits=-6.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 27 Apr 2011 18:01:40 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p3RI1VQJ031269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Apr 2011 14:01:32 -0400 Received: from host1.jankratochvil.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p3RI1SG9017363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Apr 2011 14:01:31 -0400 Received: from host1.jankratochvil.net (localhost [127.0.0.1]) by host1.jankratochvil.net (8.14.4/8.14.4) with ESMTP id p3RI1R3E004692; Wed, 27 Apr 2011 20:01:27 +0200 Received: (from jkratoch@localhost) by host1.jankratochvil.net (8.14.4/8.14.4/Submit) id p3RI1Pui004688; Wed, 27 Apr 2011 20:01:25 +0200 Date: Wed, 27 Apr 2011 18:02:00 -0000 From: Jan Kratochvil To: Pedro Alves Cc: Tom Tromey , gdb-patches@sourceware.org, Sergio Durigan Junior Subject: Re: [PATCH 2/6] Introduce `pre_expanded sals' Message-ID: <20110427180124.GA3466@host1.jankratochvil.net> References: <201104121218.08910.pedro@codesourcery.com> <201104181938.28644.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201104181938.28644.pedro@codesourcery.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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: 2011-04/txt/msg00519.txt.bz2 On Mon, 18 Apr 2011 20:38:28 +0200, Pedro Alves wrote: > (ignoring that frontends aren't prepared to have a > breakpoint map to more than one source file:line) I do not address this part in this mail, I do not know much about it. > Now, do "break A::A". [...] > (gdb) info breakpoints > Num Type Disp Enb Address What > 1 breakpoint keep y > 1.1 y 0x00000000004005d2 in A::A() at foo.cc:33 > 1.2 y 0x00000000004005ec in A::A() at foo.cc:33 > 1.3 y 0x00000000004005d2 in A::A(int) at foo.cc:38 > 1.4 y 0x00000000004005ec in A::A(int) at foo.cc:38 > > Now, say I didn't want to A::A(int) overload to break afterall. If I want to deal with `A::A()' and `A::A(int)' separately I will never type `break A::A' in the first place but create `break A::A()' and `break A::A(int)' as two separate breakpoints (or just one of them). > This is why I proposed in the response to Jan, that if we want > to group different "_source_ locations" under the same breakpoint, > we implement it as a 3rd hierarchy, so you'd get: I agree 3-level hierarchy is the best but I do not think it is practically worth it, it again creates a feature no normal user is going to use. > You do "break inline_func". There are two overloads, so the While offtopic in general breakpoint on inlined functions do not yet work: [Bug breakpoints/10738] Cannot set breakpoint on inlined function > (gdb) info breakpoints > Num Type Disp Enb Address What > 1 breakpoint keep y > 1.1 y "program:name" in foo_func() at blah.c:12 > 1.2 n "program:name" in bar_func() at blah.c:20 > 1.3 y "program:name" in qux_func() at blah.c:45 > > If the program changes, say the 1.2 location disappears, you've now > confused GDB --- how will it know that 1.3 is supposed to be enabled, > given that it is now the second location? (multiple variations of > this issue). Besides unspecifically broken reread_symbols during program change normally update_breakpoint_locations on any nontrivial C++ code finds HAVE_AMBIGUOUS_NAMES true, uses breakpoint_locations_match and as if the program really has changed any way the addresses will not match and specific bp_location enabled-flag will get reset back to enabled anyway. It also happens with any PIE program but that is more my fault (as its fix in Fedora is too ugly to be even submitted). > > I hit this while debugging gdb itself from time to time -- try `break > > parse_number' and guess where it gets set. > > It's not necessarily a bad thing (and not necessarily a good thing > either). If you have a big project, with a bunch of static > "foo" functions, it's not unreasonable to have "b foo" > break at the "closest" function with that name in your context. The problem with GDB is IMO that "your context" is very random, user may not be much aware there is any context, with the debuggee stopping here and there. > What would "list parse_number" do if "break parse_number" breaks > in all the instances of that static function? A good point, it should error, it needs more specific input. Thanks, Jan