Re: RFA: patch to fix multi-breakpoint enable/disable handling of inline functions

Doug Evans
2008-01-28T18:15:24Z

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
>