This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] canonical linespec and multiple breakpoints ...
- From: Tom Tromey <tromey at redhat dot com>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 05 Jul 2011 13:51:36 -0600
- Subject: Re: [RFC] canonical linespec and multiple breakpoints ...
- References: <20110505162855.GA2546@adacore.com> <m3oc3gx48l.fsf@fleche.redhat.com> <83bozgmhil.fsf@gnu.org> <m3oc2pxjds.fsf@fleche.redhat.com> <83k4dcd1bh.fsf@gnu.org> <m3r56bdoh9.fsf@fleche.redhat.com> <m362nmarbv.fsf@fleche.redhat.com> <20110704192005.GQ2407@adacore.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