This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] deleting breakpoints inside of 'commands' [Repost]
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: Re: [RFA] deleting breakpoints inside of 'commands' [Repost]
- From: Fernando Nasser <fnasser at cygnus dot com>
- Date: Wed, 26 Sep 2001 16:01:16 -0400
- CC: Kevin Buettner <kevinb at cygnus dot com>, Don Howard <dhoward at redhat dot com>, gdb-patches at sources dot redhat dot com, Fernando Nasser <fnasser at redhat dot com>, Michael Snyder <msnyder at cygnus dot com>
- Organization: Red Hat , Inc. - Toronto
- References: <Pine.LNX.4.33.0109211638230.1755-100000@theotherone> <1010925001014.ZM30380@ocotillo.lan> <3BAFE360.9080904@cygnus.com>
Andrew Cagney wrote:
>
> >
> > I've looked your patch over, and it looks correct to me. Having said
> > that, I think that the correctness of this patch is much less obvious
> > than the version that made a copy of the command chain associated with
> > a breakpoint. I don't fault you for this; the changes in your current
> > patch are somewhat more distributed which means that there's more code
> > to consider (and more ways for something to get fouled up later on).
>
> And guess what (sorry but this is funny :-) I suspect it does contain a
> bug. Try:
>
> break main
> commands
> delete NN
> leak-memory
> end
>
> The command ``leak-memory'' is invalid and will lead to an error() call
> and that will in turn long jump over the code that would free the list.
>
> While the duplicate version contains the same bug, I suspect it is
> easier to fix vis:
>
> o duplicate list
> o add list to a cleanup
> o run command
> o do cleanups
>
> I suspect to do this with the non-duplicate version you'll need to add a
> catch_exceptions() call (nee catch_errors()) and check the state of that
> ->execute variable to figure out what to do.
>
I don't see why it is not possible to register a cleanup in Don's latest
solution. The function would do nothing unless a "delete NN" was executed
before we bail out.
> I do tend to agree with Kevin though. Some times simplicity is best.
>
I wish you have thought like that in previous instances. ;-)
And I don't think Don's latest patch is complex, or considerably more
complex than the simplistic copy approach (or hack!). It is elegant
(although Kevin's comments are valid and should be incorporated).
If Don can add a cleanup function and do the polishing suggested by Kevin
on his last patch I suggest that we stick with that one.
--
Fernando Nasser
Red Hat - Toronto E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9