From: Vladimir Prus <ghost@cs.msu.su>
To: Nick Roberts <nickrob@snap.net.nz>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [PATCH] Re: bug in mi when setting breakpoint
Date: Sun, 20 Jan 2008 10:08:00 -0000 [thread overview]
Message-ID: <200801201307.44269.ghost@cs.msu.su> (raw)
In-Reply-To: <18322.28514.745522.314492@kahikatea.snap.net.nz>
On Sunday 20 January 2008 00:45:06 Nick Roberts wrote:
> > To clarify -- are you suggesting what we should first create breakpoints
> > for all overloaded function, and then remove those we don't need, in MI?
>
> In Emacs, multiple breakpoints are only created when the user specifies the
> overloaded function in the GUD buffer (if he clicks on the fringe in an
> overloaded function in the source buffer he only gets one breakpoint at the
> line on which he clicked).
>
> If GDB sets all these breakpoints, unwanted ones could then be deleted manually
> either by typing "delete BKPTNO" in the GUD buffer, or clicking on individual
> breakpoint icons in the fringe of the source buffers.
I don't think such solution is entirely satisfactory, for the following reason:
1. UI should not require to type GDB command for such basic task as adding
breakpoints.
2. Overloaded functions can be scattered over several source file, so clicking
on fringe is highly inconvenient -- the files might not be even open.
3. Assuming we have a list of breakpoints (which Eclipse and KDevelop do), we
surely can delete breakpoints there. However, adding unwanted breakpoints right
away will not be good in non-stop mode:
- Some threads might already stop on unwanted breakpoints before you delete them
- You might run out of hardware resources while setting unwanted breakpoints
I think it's more clear to set only those breakpoints that user want to set,
as opposed to setting all of them, and then removing undesired ones.
- Volodya
next prev parent reply other threads:[~2008-01-20 10:08 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20071216125625.GE4783@coin>
[not found] ` <18277.36237.521792.245470@kahikatea.snap.net.nz>
[not found] ` <18316.10856.89097.335103@kahikatea.snap.net.nz>
2008-01-16 22:37 ` Nick Roberts
2008-01-17 14:26 ` Vladimir Prus
2008-01-17 20:35 ` Nick Roberts
2008-01-19 11:52 ` Vladimir Prus
2008-01-19 21:45 ` Nick Roberts
2008-01-20 10:08 ` Vladimir Prus [this message]
2008-01-20 10:38 ` Nick Roberts
2008-01-20 11:09 ` Vladimir Prus
2008-01-20 20:32 ` Nick Roberts
2008-01-21 7:28 ` Vladimir Prus
2008-01-21 8:41 ` Nick Roberts
2008-01-29 20:15 ` 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=200801201307.44269.ghost@cs.msu.su \
--to=ghost@cs.msu.su \
--cc=gdb-patches@sources.redhat.com \
--cc=nickrob@snap.net.nz \
/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