From: Jerome Guitton <guitton@adacore.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: Tom Tromey <tromey@redhat.com>, gdb-patches@sourceware.org
Subject: Re: [RFC] canonical linespec and multiple breakpoints ...
Date: Tue, 05 Jul 2011 09:20:00 -0000 [thread overview]
Message-ID: <20110705085308.GA16280@adacore.com> (raw)
In-Reply-To: <20110704192005.GQ2407@adacore.com>
Joel Brobecker (brobecker@adacore.com):
> 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.
I would suggest a slightly different rule: all breakpoints are still
"multiple" by default. No "static" one. But, in the case of 'set
multiple-symbols ask' and when one symbol is selected, then a
breakpoint will be set, whose location will not be ambiguous (it will
be "canonicalized"). So this "multiple" breakpoint will always
resolve to only one location. If more than one choice is selected,
same thing, with one breakpoint per choice.
I'd rather avoid adding a special breakpoint kind for 'ask'. Just to
keep it simple.
next prev parent reply other threads:[~2011-07-05 8:53 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-05 16:29 Joel Brobecker
2011-05-05 20:50 ` Tom Tromey
2011-05-05 22:40 ` Joel Brobecker
2011-05-06 3:20 ` Jan Kratochvil
2011-05-06 4:42 ` Joel Brobecker
2011-05-06 18:08 ` Matt Rice
2011-05-06 7:16 ` Eli Zaretskii
2011-05-06 19:18 ` Tom Tromey
2011-05-06 7:10 ` Eli Zaretskii
2011-05-26 21:06 ` Tom Tromey
2011-05-27 7:56 ` Eli Zaretskii
2011-06-30 21:35 ` Tom Tromey
2011-07-01 18:06 ` Tom Tromey
2011-07-02 6:35 ` Eli Zaretskii
2011-07-05 19:52 ` Tom Tromey
2011-07-05 21:07 ` Eli Zaretskii
2011-07-05 21:46 ` Tom Tromey
2011-07-04 19:32 ` Joel Brobecker
2011-07-05 9:20 ` Jerome Guitton [this message]
2011-07-05 15:24 ` Joel Brobecker
2011-07-05 19:53 ` Tom Tromey
2011-07-26 21:06 ` Tom Tromey
2011-07-27 15:10 ` Matt Rice
2011-07-27 16:23 ` Jan Kratochvil
2011-07-28 15:18 ` Matt Rice
2011-08-02 15:33 ` Pedro Alves
2011-08-02 17:09 ` Tom Tromey
2011-08-02 18:00 ` Pedro Alves
2011-11-18 19:31 ` Tom Tromey
2012-02-16 23:31 ` Tom Tromey
2011-07-02 6:15 ` Eli Zaretskii
2011-07-05 20:00 ` Tom Tromey
2011-05-27 10:50 ` Matt Rice
2011-05-29 13:01 ` Matt Rice
2011-07-05 20:01 ` Tom Tromey
2011-07-06 2:32 ` Matt Rice
2011-09-18 13:47 Avi Gozlan
2011-10-03 16:28 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110705085308.GA16280@adacore.com \
--to=guitton@adacore.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=tromey@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox