From: Fernando Nasser <fnasser@redhat.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Michael Snyder <msnyder@cygnus.com>,
Don Howard <dhoward@redhat.com>,
gdb-patches@sources.redhat.com
Subject: Re: [RFA] deleting breakpoints inside of 'commands' [Repost]
Date: Tue, 18 Sep 2001 08:09:00 -0000 [thread overview]
Message-ID: <3BA7628F.371ABBDD@redhat.com> (raw)
In-Reply-To: <3BA7608F.3040104@cygnus.com>
Andrew Cagney wrote:
>
> >> Is it worth the effort? Is this duplication costly
> >> compared to everything else already being done by
> >> bpstat_do_actions? Or am I worrying over nothing?
>
> I think this is in the noise. GDB has performance problems with very
> large symbol files, it doesn't have problems with 3 line breakpoint scripts.
>
Why 3 line? There are very long breakpoint scripts around.
Furthermore, when using breakpoint scripts to track some bugs (sometimes
"condition" is not enough) it may be desirable to minimize the artifact.
> > I share your concerns. And I see no reason why this should be allowed
> > --
> > the script can always "disable" its own breakpoint with the same effect
> > for all practical purposes.
> >
> > A patch adding a "cannot delete self" error message would be nice.
>
> I would really rather not see GDB introduce, undocumented, edge
> conditions like this. I think the patch Don submitted had the very nice
> effect of eliminating the need for such a special case.
>
If at least it would make the copy only when needed (i.e., when someone
is
trying to delete the breakpoint that has the script attached on it)
things
would not be that bad.
Michael, do you remove your objection or does it still stands after
Andrew's
arguments?
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
next prev parent reply other threads:[~2001-09-18 8:09 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-17 9:34 Don Howard
2001-09-17 15:39 ` Michael Snyder
2001-09-18 6:56 ` Fernando Nasser
2001-09-18 7:56 ` Andrew Cagney
2001-09-18 8:09 ` Fernando Nasser [this message]
2001-09-18 10:34 ` Michael Snyder
2001-09-18 17:47 ` Andrew Cagney
2001-09-18 18:03 ` Michael Snyder
2001-09-19 7:20 ` Fernando Nasser
2001-09-19 8:17 ` Andrew Cagney
2001-09-19 9:22 ` Fernando Nasser
2001-09-19 11:44 ` PRMS not TODO: " Andrew Cagney
2001-09-19 9:33 ` Don Howard
2001-09-19 12:08 ` Kevin Buettner
2001-09-19 12:18 ` Michael Snyder
2001-09-19 13:09 ` Kevin Buettner
[not found] ` <3BA905AD.5F8F1A68@redhat.com>
2001-09-19 14:22 ` Kevin Buettner
2001-09-19 14:44 ` Fernando Nasser
2001-09-20 15:24 ` Don Howard
2001-09-20 18:05 ` Andrew Cagney
[not found] <Pine.LNX.4.33.0109211638230.1755-100000@theotherone>
2001-09-24 17:10 ` Kevin Buettner
2001-09-24 17:33 ` Kevin Buettner
2001-09-24 18:52 ` Andrew Cagney
2001-09-26 13:07 ` Fernando Nasser
2001-09-26 14:20 ` Kevin Buettner
2001-09-26 14:57 ` Fernando Nasser
2001-09-26 15:09 ` Andrew Cagney
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=3BA7628F.371ABBDD@redhat.com \
--to=fnasser@redhat.com \
--cc=ac131313@cygnus.com \
--cc=dhoward@redhat.com \
--cc=gdb-patches@sources.redhat.com \
--cc=msnyder@cygnus.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