public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Vladimir Prus <ghost@cs.msu.su>
To: gdb@sources.redhat.com
Subject: Re: Multiple breakpoint locations
Date: Wed, 14 Nov 2007 19:00:00 -0000	[thread overview]
Message-ID: <fhfgju$5ce$1@ger.gmane.org> (raw)
In-Reply-To: <u4pfoejzb.fsf@gnu.org>

Eli Zaretskii wrote:

>> From:  Vladimir Prus <ghost@cs.msu.su>
>> Date:  Wed, 14 Nov 2007 09:13:16 +0300
>> 
>> >> > Sorry, I don't understand why; can you please elaborate?  Removing a
>> >> > breakpoint instruction from a specific address is a primitive
>> >> > operation of the target back-end; why can't we use it for that
>> >> > single address?
>> 
>> Because after that, the output of 'info break' will no longer correspond
>> accurately to what the program is.
> 
> I need it to correspond to the way I want the program to be stopped,
> not to all possible ways a source-level locations specification can be
> interpreted in terms of an address.  The latter is of course a correct
> starting point, but if I then chose that some of the addresses don't
> make sense for me, there's no reason I should see them just for
> completeness' sake.
> 
>> > Well, my big picture is that today we have no solution for the
>> > following use case: (a) I set a breakpoint that results in multiple
>> > locations; (b) I look at "info break" and realize that some of these
>> > locations are irrelevant for the problem I'm debugging, and I don't
>> > want the program to stop there (e.g., maybe stopping there will
>> > disrupt some timing); (c) I want to remove these locations from the
>> > breakpoints list.
>> 
>> You disable those locations, and gdb no longer stops there.
> 
> That's just a workaround.  The same logic could be used to argue that
> there's no need to have the "delete" command at all: you can always
> disable the critter.

I disagree. breakpoint is something you create yourself, and it's
natural you can delete something you've created. Locations exist
in the program independent of you, and it's natural to be able
to disable some locations. And, BTW, once you've deleted a breakpoint,
you can create it afresh because you presumably remember how it was
created. If you delete a location, how you recover it back? By
deleting the breakpoint, creating it again, and losing enable/disable
state on other unrelated locations?

- Volodya


  reply	other threads:[~2007-11-14 19:00 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-13 19:15 Nick Roberts
2007-11-13 19:28 ` Vladimir Prus
2007-11-13 19:59   ` Daniel Jacobowitz
2007-11-13 20:09   ` Nick Roberts
2007-11-13 20:14     ` Daniel Jacobowitz
2007-11-13 20:18     ` Bob Rossi
2007-11-13 20:19     ` Vladimir Prus
2007-11-13 22:03     ` Andreas Schwab
2007-11-14  6:20       ` Vladimir Prus
2007-11-14 10:12         ` Andreas Schwab
2007-11-14 21:26           ` Jim Blandy
2007-11-14 21:34             ` Vladimir Prus
2007-11-14 22:08             ` Andreas Schwab
2007-11-15  4:08             ` Eli Zaretskii
2007-11-15 13:37               ` Daniel Jacobowitz
2007-11-15 16:50               ` Jim Blandy
2007-11-13 22:18   ` Eli Zaretskii
2007-11-13 23:39     ` Douglas Evans
2007-11-14  4:17       ` Eli Zaretskii
2007-11-14  5:02         ` Joel Brobecker
2007-11-14  6:13         ` Vladimir Prus
2007-11-14 18:54           ` Eli Zaretskii
2007-11-14 19:00             ` Vladimir Prus [this message]
2007-11-17 11:55 ` Eli Zaretskii
2007-11-17 12:07 ` Eli Zaretskii
2007-11-17 14:14   ` Vladimir Prus
2007-11-17 15:36     ` Eli Zaretskii
2007-11-18  1:32       ` Nick Roberts
2007-11-18  2:26         ` Daniel Jacobowitz
2007-11-18  8:47           ` Nick Roberts
2007-11-19 12:57             ` Daniel Jacobowitz

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='fhfgju$5ce$1@ger.gmane.org' \
    --to=ghost@cs.msu.su \
    --cc=gdb@sources.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).