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: Kevin Buettner <kevinb at cygnus dot com>
- Subject: Re: [RFA] deleting breakpoints inside of 'commands' [Repost]
- From: Michael Snyder <msnyder at cygnus dot com>
- Date: Wed, 19 Sep 2001 12:17:58 -0700
- CC: Don Howard <dhoward at redhat dot com>, Andrew Cagney <ac131313 at cygnus dot com>, gdb-patches at sources dot redhat dot com, Fernando Nasser <fnasser at cygnus dot com>
- Organization: Red Hat
- References: <Pine.LNX.4.33.0109190846200.6246-100000@theotherone> <1010919190753.ZM14865@ocotillo.lan>
Kevin Buettner wrote:
>
> On Sep 19, 9:34am, Don Howard wrote:
>
> > > > I have the same concerns.
> > > > We haven't heard from Don yet. Maybe he has some compromise solution.
> > > >
> > > > Anyway, I find the copy solution a hack.
> > > >
> > > > One way to fix this is to have the chain of commands as an object with
> > > > use count. It is only freed when the count is down to zero again.
> > > >
> > > > When you associate it with a breakpoint it goes up to 1. When you
> > > > get it to execute it goes up to 2.
> > > >
> > > > When a breakpoint is deleted, it deallocates it. If the count goes
> > > > to zero memory is freed. But if the script is being executed (and
> > > > is deleting self) the count will go to 1 and nothing else happens
> > > > until the script finishes executing and the chain is freed (then
> > > > the count goes to zero and memory is deallocated).
> > >
> > > Rememeber, the patch doesn't have to be perfect, just acceptable. In
> > > this case, the change eliminates a stray pointer problem (which would
> > > likely still occure with reference counters) and hence makes gdb far
> > > more robust - I put robustness and maintainability at a much higher
> > > priority level then performance.
> > > When someone manages to demonstrate that the copy is a significant
> > > overhead (using ``set maint profile on/off'' [:-)]) then I think we
> > > should refine the code to do what you propose (or gasp add a garbage
> > > collector :-/). However, Don, if you're upto the task.
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > I don't understand what you are asking here. I've followed the thread
> > and it seems that the unconditional copy is not acceptable. I will look
> > at the suggestions that Fernando and Michael have suggested and see if I
> > can come up with another patch.
>
> I don't think that reference counting is the right way to go. You'll
> be adding complexity to GDB in the form of making certain parts of GDB
> responsible for updating the reference counts. Also, there's the
> overhead of maintaining the reference counts. I agree that making a
> copy of the commands might be a little bit slower, but it has the
> advantage of being simple which makes it easier to verify correctness.
>
> A slightly more complicated scheme would examine the command list for
> commands which may alter/delete the list and then tag the entire list
> as one that needs to be copied. This would be done ahead of time
> (probably at the time that the list is created). There's no point in
> scanning the command list every time we want to execute the commands
> because it's nearly as cheap to make a copy. (Both are linear time
> operations.)
I thought about this, but then I thought that the command list
might include user-defined commands, which in turn might call
delete. That makes it a recursive problem. And I'm not sure
whether user commands might be re-defined later (after this
step has been done.)