Re: RFA: implement ambiguous linespec proposal

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

Tom> E.g., suppose you do "break something::method" and there are 5 methods.
Tom> Suppose you have multiple-symbols=ask and you pick something::method(int).
Tom> Then, we will have a breakpoint whose linespec is "something::method"
Tom> but whose filter is "something::method(int)".

Joel> I wonder if we could start filtering based on function fully qualified
Joel> name, and profile (argument types) as well. In other words, if the user
Joel> does:
Joel>         (gdb) break foo
Joel> and there are several functions named foo, then we'd have a filter
Joel> that says:
Joel>         package1.foo(integer)
Joel>         package2.instantiation.foo(float)

Yeah, this is actually what happens in multiple-symbols=ask mode: we
present the canonical forms to the user, and record as the filter the
one that he chooses.

An implication of this is that we don't discriminate more finely than
what can be encoded in the canonical form.  So, for example, one cannot
set a symbolic (as opposed to by-address) breakpoint at a single point
of inlining -- because the canonical form for the inlined function will
be identical across inlined instances.

I don't know if that description makes any sense outside my head :)

Joel> The only road-block I can foresee is the fact that I am unclear on
Joel> the resolution rules in Ada. I think they can get quite tricky, and
Joel> reproducing that in GDB might be a fair amount of work (if possible
Joel> at all). On the other hand, it would be nice to have that, because
Joel> we somewhat have something like that already for resolving inferior
Joel> function calls from GDB, but it's fairly primitive, and I think we
Joel> can call the wrong function sometimes (I just forgot the details).

Yeah, the issue in this sub-thread is whether or not to perform name
lookup.

My view is that if the name lookup is context-dependent, then we should
not do it.  E.g., in the C++ example, having "break m" search namespaces
would either require us to (1) rewrite the linespec from "m" to
something else for purposes of re-evaluation, or (2) store the context.
I tend to think neither one is very good and that we slipped into doing
this in the first place by accident, not design.

Joel> Just curious: Are we planning on emitting a warning if re-evaluating
Joel> a breakpoint for which we no longer have a match for one of the entries
Joel> in the filter? This would happen if the user selected a function which,
Joel> after rebuilding the executable, no longer exists...

It just silently stays around.  I believe "info break" will show it as
pending.

Joel> I actually like this design better. In fact, we don't even need the
Joel> filter to consist of strings. It could very well be something more
Joel> elaborate...

Yeah; we discussed that at some point, but I didn't seem to need it.
It is still available as a future change though.

Tom