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

[Kevin Buettner <kevinb at cygnus dot com>]

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

Kevin