Re: RFA: implement ambiguous linespec proposal

[Joel Brobecker <brobecker@adacore.com>]

> I think FILE:FUNCTION:LINE is a good form to provide to users, but it
> seems to me that it is incorrect to rewrite a user's "FUNCTION" linespec
> into this form.  My reason is that it seems like it would do the wrong
> thing if the line number changes -- the linespec would stop working,
> rather than re-evaluate correctly.  How do you deal with this problem?

Touche :-)! We do not deal with that issue. It hasn't been a real
problem so far, but it would be nice to have it solved nonetheless.

> Joel> The question is, can we use that same form for everyone? I thought
> Joel> you were going to do unconditional rewriting of the location string,
> Joel> but now I'm not so sure anymore...
> 
> With my patch, only relative forms require rewriting.  I think those are
> just "break LINE" and "break LABEL".  The former is rewritten to
> FILE:LINE, and the latter to FUNCTION:LABEL.

OK, this makes sense.

> With multiple-symbols=ask, we also do filtering based on the "canonical
> form", which is different from the string used to re-evaluate.
> 
> E.g., suppose you do "break something::method" and there are 5 methods.
> Suppose you have multiple-symbols=ask and you pick something::method(int).
> Then, we will have a breakpoint whose linespec is "something::method"
> but whose filter is "something::method(int)".

I wonder if we could start filtering based on function fully qualified
name, and profile (argument types) as well. In other words, if the user
does:

        (gdb) break foo

and there are several functions named foo, then we'd have a filter
that says:

        package1.foo(integer)
        package2.instantiation.foo(float)

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

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

> I chose this somewhat odd design over the more straightforward
> rewriting of the linespec because there are canonical forms which are
> not yet suitable as input to linespec.

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

-- 
Joel