Re: [RFC] canonical linespec and multiple breakpoints ...

[Joel Brobecker <brobecker at adacore dot com>]

> Here is my proposal for how to handle ambiguous linespecs.  First I'll
> describe it in general terms, with a few specifics about the
> implementation.  Then I'll describe how it handles each scenario I
> posted yesterday.

Overal, I think that this is a very nice proposal.

> I propose a simple rule for the handling of ambiguous linespecs: a
> breakpoint whose argument is ambiguous will fire at all matching
> locations.

I think that this is a good general rule, and something we should
encourage our users to use. But it seems that it does not cover
the case where 'set multiple-symbols ask' is in use, does it?
My understanding, when `ask' is that, if the user selects `all',
then we're in the case above (fire at all locations, add new locations
as we discover them), but if the user selects a sub-sets of the
potential matches, what should we do?

My suggestion, in that case, is to make the list of selected
locations static.  In other words, we do not add new locations
as they get discovered.

The typical scenario is when we have multiple instantiations of
a given generic, and the user is only interested in debugging
one, or at least a small subset.  In that case, a typical user
debugging using a GUI or an IDE will click on the code, which
is often translated into a FILE:LINE linespec.

> In order to properly re-set breakpoints, we need a canonical form of the
> linespec.  Currently this is done by constructing a new canonicalized
> linespec.  In my proposal we will replace this with a structure, the
> better to add more precise behavior without needing to construct
> linespec syntax for every possible case.  E.g., we can have a bit
> indicating whether this canonical linespec matches symbols without
> debuginfo.

I think it's important to have some kind of canonical form that
the user's can use as the linespec as well. That way, they can
enter a linespec that, in the vast majority of cases, is not
ambiguous.  For our purposes, FILE:FUNCTION:LINE has worked really
well...

> I am not sure how the breakpoint location information should be arranged
> internally.  Perhaps each bp_location will need a canonical linespec
> struct.

I would think so.

> Tom> 4. Set a pending breakpoint.
> Tom>    (gdb) break lib_function
> Tom> 5. The same, but the pending name is ambiguous.
> 
> These both make a pending breakpoint; inferior changes may cause
> locations to be added or removed.

So, pending breakpoints are implicitly treated as breakpoints
with multiple-symbols set to `all', right? I think that'd be fair.

> Tom> 7. 'break main', then start multiple inferiors
> 
> Each new inferior causes new locations to be added; gdb stops at the
> 'main' of each one.

I hadn't thought about that. I thought that breakpoints were specific
to a given inferior, but I guess we'd want that, at least in certain
scenarios (the ones where we're trying to follow a process and all
its children for instance). I think this behavior makes sense, new
inferior and new SOs can be treated the same.

> Tom> 8. Any of the above, but with a breakpoint condition.
> Tom>    Of particular importance is the case where the condition cannot be
> Tom>    parsed in one location.
> 
> This, I think, is the one bad part of this proposal.  When a location is
> added to a breakpoint, it may cause the condition to no longer be
> parseable.
> 
> In this situation I think we should change gdb in 2 ways, to give the
> user more control:
> 
> 1. When a condition is no longer parseable, provide the option to stop
>    the inferior so the user can correct it.
> 2. Also provide a way for the user to respecify the breakpoint location.
> 
> For the latter I think something like:
> 
>   modify breakpoint N location LINESPEC

Looks good.  By extension, we could also allow 'modify breakpoint N
condition', as an alias of the 'cond' command (I am not suggesting
this too seriously, just to say that I like the `modify <object>'
syntax, which we can extend for other stuff we might need in the
future).

-- 
Joel