From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Buettner To: Andrew Cagney , Fernando Nasser Cc: gdb-patches@sources.redhat.com, Don Howard , Fernando Nasser , Kevin Buettner , Michael Snyder Subject: Re: [RFA] deleting breakpoints inside of 'commands' [Repost] Date: Wed, 26 Sep 2001 14:20:00 -0000 Message-id: <1010926211948.ZM2311@ocotillo.lan> References: <1010925001014.ZM30380@ocotillo.lan> <3BAFE360.9080904@cygnus.com> <3BB2340C.CB386069@cygnus.com> X-SW-Source: 2001-09/msg00368.html On Sep 26, 4:01pm, Fernando Nasser wrote: > 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. Here are my preferences... I like the patch that makes a copy the best since the changes are easy to understand and localized to one function. Next best would be a patch (unwritten as of now) which implements reference counts for these command chains. I think that a lot of folks understand reference counts and it takes less time to grok code written with this design pattern. In all likelyhood, such a patch would look somewhat similar to Don's latest patch though; i.e, the changes would be distributed among several files and would likely be in the same functions that Don has touched with his latest patch. Next best would be Don's latest patch revised to use an enum for the ``execute'' member. I think this code would be easier to understand by giving the 0, 1, and 2+ values actual names that are meaningful. I still have concerns about what might happen if bpstat_do_actions() is ever executed recursively... I don't think this ever happens, so it's probably a non-issue, but if it could happen, then a reference counting mechanism would definitely be superior. (All of the above approaches need to make use of a cleanup.) Kevin P.S. I'd like to publicly thank Don for all the hard work he has put in on this patch. I imagine it must be frustrating to be told to do the patch one way by one person, a different way by a second, and still a different way by a third...