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

[Don Howard <dhoward at redhat dot com>]

On Wed, 19 Sep 2001, Andrew Cagney 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.


-- 
-Don
dhoward@redhat.com
gdb engineering