This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFA: patch to fix multi-breakpoint enable/disable handling of inline functions
- From: "Doug Evans" <dje at google dot com>
- To: "GDB Patches" <gdb-patches at sourceware dot org>
- Date: Wed, 6 Feb 2008 11:08:57 -0800
- Subject: Re: RFA: patch to fix multi-breakpoint enable/disable handling of inline functions
- References: <20071016001816.F059B1C7E69@localhost> <e394668d0711141449o2e9c9b19u3d3f29a6299c936c@mail.gmail.com> <e394668d0711261522s32aff5a6h3b00aa52b76a304c@mail.gmail.com> <200712272136.04574.vladimir@codesourcery.com> <e394668d0801281014t517449e7jb3521ef0b5a02b79@mail.gmail.com>
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 <dje@google.com> wrote:
> Ping ...
>
>
> On Dec 27, 2007 10:36 AM, Vladimir Prus <vladimir@codesourcery.com> 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
> >
>