Re: Problems with hook-stop

[Daniel Jacobowitz <drow@false.org>]

On Thu, Sep 27, 2007 at 05:25:33PM -0700, Carl Shapiro wrote:
> On 9/27/07, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > Since SIGTRAP has a very special meaning for debugging, it's probably
> > unwise to play games like this.
> 
> The problem I am having is not specific to SIGTRAP.  You can replace
> the interrupt instruction with a kill(2), providing any signal you'd
> like as an argument.  The stop hook will fails execute every other
> time.

Thank you for the test case.  This was very useful.

The problem is that we are still running the stop hook for the
first stop when the program stops the second time.  Basically,
the stop "command" has been run again from inside the first
hook-stop.  There's a safety check for recursive hooks to prevent
GDB blowing out its stack.  If that weren't there you'd have an
even more unpleasant bug to report.

To fix this we would need to make a decision about what happens when
a hook (or a breakpoint commands list, it's basically the same thing)
runs the target.  We don't want to necessarily abort the hook.
Consider:

define hook-stop
  call dump_state ()
  echo done
end

Assuming there's no breakpoint or crash in dump_state, then we should
run the function to completion and continue executing the stop hook.

Maybe we should handle hooks and commands lists specially when they
end in continue or signal.  Basically a tail recursion optimization.

I'm not going to try to do that right now, but I hope this explanation
is helpful :-)

-- 
Daniel Jacobowitz
CodeSourcery