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

[Tom Tromey <tromey@redhat.com>]

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

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

This was part of the proposal but I think it should have been more
prominent.

My proposal was that in 'ask' mode, 'break' makes a separate
canonicalized breakpoint for each location the user requests.

I had proposed making the 'all' choice make N different breakpoints,
each "static".  But now I think that 'all' should mean "make a dynamic
breakpoint covering all locations", and the user can create separate
static breakpoints by entering "2-57" (e.g.) at the prompt.  This gives
the user a way to achieve multiple-symbols=all behavior without having
to temporarily change the setting.

I think we must specify what "static" means -- by specifying the
canonicalization algorithm.  When I consider the difference between your
proposal and Jerome's, I think the distinction largely relies on what
exactly it means to canonicalize a location.

FWIW I would be satisfied with any of several possible solutions
(including yours and Jerome's) to the multiple-symbols=ask scenario.

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

Do IDEs actually run in multiple-symbols = ask mode?
My understanding was that these interactive prompts caused headaches for
MI users.

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

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

When I wrote this I was specifically thinking of the situation where a
breakpoint has some matches with debuginfo and some without.  I didn't
see much value in having a linespec covering the "functions named X
without debuginfo" case.

FILE:FUNCTION:LINE makes sense to me, I think it would be useful for C++
templates as well.

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

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

Yes.

Tom