Re: [RFA] deleting breakpoints inside of 'commands' [Repost]

[Michael Snyder <msnyder@cygnus.com>]

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.)