From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Snyder To: Kevin Buettner Cc: Don Howard , Andrew Cagney , gdb-patches@sources.redhat.com, Fernando Nasser Subject: Re: [RFA] deleting breakpoints inside of 'commands' [Repost] Date: Wed, 19 Sep 2001 12:18:00 -0000 Message-id: <3BA8EF66.43ED46F5@cygnus.com> References: <1010919190753.ZM14865@ocotillo.lan> X-SW-Source: 2001-09/msg00264.html 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.)