Re: [RFA]: infrun.c/proceed change

[Guy Harris <guy at netapp dot com>]

> It looks harmless enough although I'm not sure what situtation was
> encountered to prompt the change?

The checkin commentary in our Perforce tree for that change was

        In "proceed()", if we weren't explicitly told to single-step one
        instruction but decided to do so ourselves, initialize
        "step_frame_address" and "step_sp", so that code in
        "wait_for_inferior()" that uses "step_sp" to check whether we've
        made a procedure call (by checking whether the current SP is
        "below" "step_sp") doesn't conclude incorrectly that we haven't.

        This appears to fix up the "continue" part of bug 24131. 

24131 is a bug in our bug system (as noted in another mail, we use our
bug system for bugs in tools as well as for bugs in our own software).

The problem is that, to quote the bug:

	It is very common for [the submitter of the bug] to set a
	breakpoint at a function, hit the breakpoint, change a variable
	and type "c" for continue, at which point it never does another
	damn thing.

The problem is, I think, caused by the program being debugged arranging
that alarm-clock signals be delivered quite frequently (it uses SIGUSR1
for various reasons); the comment I put into the bug while investigating
it was:

	It appears that, if I arrange that we arrange in "proceed()" to
	set the "step_sp" variable (because "proceed()", when continuing
	from a breakpoint, forces single-stepping so that it can put the
	real instruction back in place of the breakpoint and then, after
	executing that instruction, put the breakpoint back, but GDB
	currently only sets "step_sp" higher up in the call chain, and
	various tests inside "wait_for_inferior()" get confused by
	"step_sp" being 0), the code to handle the fact that said
	single-step ends up in "__sigtramp" because a SIGUSR1 clock
	interrupt went off doesn't get confused, so that if the signal
	hooks are commented out, I can at least continue from the
	breakpoint without a problem.

Whether this is the *right* fix for that problem is another matter, but
it seems to work, at least.