From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18925 invoked by alias); 27 Dec 2007 18:37:04 -0000 Received: (qmail 18917 invoked by uid 22791); 27 Dec 2007 18:37:03 -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; Thu, 27 Dec 2007 18:36:57 +0000 Received: (qmail 25835 invoked from network); 27 Dec 2007 18:36:55 -0000 Received: from unknown (HELO 172.16.unknown.plus.ru) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 27 Dec 2007 18:36:55 -0000 From: Vladimir Prus To: "Douglas Evans" Subject: Re: RFA: patch to fix multi-breakpoint enable/disable handling of inline functions Date: Thu, 27 Dec 2007 19:20:00 -0000 User-Agent: KMail/1.9.6 Cc: gdb-patches@sources.redhat.com References: <20071016001816.F059B1C7E69@localhost> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712272136.04574.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-12/txt/msg00423.txt.bz2 On Tuesday 27 November 2007 02:22:40 Douglas Evans wrote: > How about this version? > > Here I use libiberty/hashtab.c to determine function name ambiguity. > > It turns out the bug exists for constructors too. I.e. > l->function_name for "Derived" in the gdb.cp/mb-ctor testcase is > "Derived" for both locations. I wonder if for this particular > situation l->function_name should record an "enhanced" name to > distinguish them. Hi Doug, sorry for slow reply. I think this version of patch is fine, but I don't have the right to approve it. Speaking about the constructors issue you bring -- right, for reasons unknown the function name for constructor does not include parameter types (either in plain text, or mangled). Storing mangled name would require two bits: 1. Learning how to get than mangled name. 2. Changing expand_line_sal_maybe to cope with this. Right now, if you set breakpoint at function name, we first expand locations, and then check that all newly found locations belong to a function of the same name. So, if you set a breakpoint on a specific instantiation of template function that is inline, you'd have breakpoint on all inlined instances of that instantiations, but not on other instantiations. Now if we use mangled name of constructor, then setting breakpoint on constructor by name won't set breakpoint on the other constructor. It might require some tweaks to get right - Volodya