This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


Michael Snyder wrote:
> 
> Don Howard wrote:
> >
> > [This is a repost with a few nits fixed, and addressed to the correct
> > list =) ]
> >
> > Here is an other variation on how to deal with 'commands' scripts that
> > delete their own breakpoint.  The patch below makes a copy of the
> > commands list before executing it and deletes the copy when finished.
> > Comments?
> 
> You mean other than "the concept makes my head hurt"?   ;-)
> 
> Well, let's see... seems like making a copy unconditionally
> is going to slow down the execution of all command lists,
> for the benefit of those few that delete themselves.
> 
> Can we think of a way to make the duplication conditional
> on the need?  That is, on the current command list being
> deleted?  Put off the cost until it becomes necessary?
> 
> I can think of one method, but it would require an extra pointer
> in the breakpoint struct.  "execute_control_command" would set
> this pointer to point to its command list, and delete_breakpoint
> would check the pointer.  If it's non-null, then the duplication
> would be done by delete_breakpoint, and the pointer updated to
> point to the duplicate.
> 
> Is it worth the effort?  Is this duplication costly
> compared to everything else already being done by
> bpstat_do_actions?  Or am I worrying over nothing?
> 

I share your concerns.  And I see no reason why this should be allowed
--
the script can always "disable" its own breakpoint with the same effect 
for all practical purposes.

A patch adding a "cannot delete self" error message would be nice.


-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]