Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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.


  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