From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2694 invoked by alias); 6 Feb 2008 19:09:18 -0000 Received: (qmail 2685 invoked by uid 22791); 6 Feb 2008 19:09:18 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 06 Feb 2008 19:09:00 +0000 Received: from zps19.corp.google.com (zps19.corp.google.com [172.25.146.19]) by smtp-out.google.com with ESMTP id m16J8wOH012410 for ; Wed, 6 Feb 2008 11:08:58 -0800 Received: from wr-out-0506.google.com (wrac57.prod.google.com [10.54.54.57]) by zps19.corp.google.com with ESMTP id m16J8TtG004810 for ; Wed, 6 Feb 2008 11:08:57 -0800 Received: by wr-out-0506.google.com with SMTP id c57so3134284wra.9 for ; Wed, 06 Feb 2008 11:08:57 -0800 (PST) Received: by 10.115.50.5 with SMTP id c5mr4783718wak.109.1202324937261; Wed, 06 Feb 2008 11:08:57 -0800 (PST) Received: by 10.114.13.5 with HTTP; Wed, 6 Feb 2008 11:08:57 -0800 (PST) Message-ID: Date: Wed, 06 Feb 2008 19:09:00 -0000 From: "Doug Evans" To: "GDB Patches" Subject: Re: RFA: patch to fix multi-breakpoint enable/disable handling of inline functions In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071016001816.F059B1C7E69@localhost> <200712272136.04574.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: 2008-02/txt/msg00124.txt.bz2 If this is still in someone's queue, let me know. Vladimir is ok with this but he can't approve it. If folks are holding off approving it because there's something they don't like but don't have time to research it further, maybe you could tell me what it is and we can both research it. On Jan 28, 2008 10:14 AM, Doug Evans wrote: > Ping ... > > > On Dec 27, 2007 10:36 AM, Vladimir Prus wrote: > > > > 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 > > >