- /* If we're in the middle of a "next" command, let the code for
- stepping over a function handle this. pai/1997-09-10
-
- A previous comment here suggested it was possible to change
- this to jump to keep_going in all cases. */
-
- if (step_over_calls > 0)
- goto step_over_function;
- else
- goto check_sigtramp2;
+ /* I'm not sure whether this needs to be check_sigtramp2 or
+ whether it could/should be keep_going.
+
+ This used to jump to step_over_function if we are stepping,
+ which is wrong.
+
+ Suppose the user does a `next' over a function call, and while
+ that call is in progress, the inferior receives a signal for
+ which GDB does not stop (i.e., signal_stop[SIG] is false). In
+ that case, when we reach this point, there is already a
+ step-resume breakpoint established, right where it should be:
+ immediately after the function call the user is "next"-ing
+ over. If we jump to step_over_function now, two bad things
+ happen:
+
+ - we'll create a new breakpoint, at wherever the current
+ frame's return address happens to be. That could be
+ anywhere, depending on what function call happens to be on
+ the top of the stack at that point. Point is, it's probably
+ not where we need it.
+
+ - the existing step-resume breakpoint (which is at the correct
+ address) will get orphaned: step_resume_breakpoint will point
+ to the new breakpoint, and the old step-resume breakpoint
+ will never be cleaned up.
+
+ The old behavior was meant to help HP-UX single-step out of
+ sigtramps. It would place the new breakpoint at prev_pc, which
+ was certainly wrong. I don't know the details there, so fixing
+ this probably breaks that. As with anything else, it's up to
+ the HP-UX maintainer to furnish a fix that doesn't break other
+ platforms. --JimB, 20 May 1999 */
+ goto check_sigtramp2;