Re: STEP_SKIPS_DELAY question, sort of

[Andrew Cagney <cagney@gnu.org>]

> Orjan Friberg wrote:
> 
>>
>> Gah.  Please ignore the previous patch (and sorry); what I posted only works when doing a continue when stopped at the branch instruction. Doing a step (which leaves us in the delay slot) followed by another step (or continue for that matter) prematurely inserts the breakpoint.
> 
> 
> Ok, second try (still concept patch though): the change in proceed is needed for when we resume from the delay slot - in that case we need to single-step again before re-inserting the breakpoint (similar to the MIPS case).  The change in handle_inferior_event (and I'll happily agree it's far more questionable) is needed for when we resume at the branch instruction itself.  Comments?

Can this new mechanism somehow superseed STEP_SKIPS_DELAY - it seems to 
be the exact oposite but there could be common ground here.

> Index: infrun.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/infrun.c,v
> retrieving revision 1.156
> diff -u -p -r1.156 infrun.c
> --- infrun.c    11 May 2004 23:30:31 -0000      1.156
> +++ infrun.c    7 Jun 2004 12:59:10 -0000
> @@ -748,6 +748,14 @@ proceed (CORE_ADDR addr, enum target_sig
>           && breakpoint_here_p (read_pc () + 4)
>           && STEP_SKIPS_DELAY (read_pc ()))
>         oneproc = 1;
> +
> +      /* If we stepped into a delay slot, and the preceding instruction
> +        will be re-executed when resuming, step again before re-inserting
> +        the breakpoint.  */
> +      if (STEP_SKIPS_IN_DELAY_P
> +         && "
> +         && STEP_SKIPS_IN_DELAY (read_pc ()))
> +       oneproc = 1;
>      }
>    else
>      {

They both seem to be asking the question: "given PC and a list of 
breakpoints, should the inferior be h/w single-stepped?".  That would 
mean pushing the alternative:
   breakpoint_here_p (read_pc () - 2)
   breakpoint_here_p (read_pc () + 4)
calls into that architecture method.

> @@ -1975,7 +1983,17 @@ handle_inferior_event (struct execution_
>        /* Don't even think about breakpoints if just proceeded over a
>           breakpoint.  */
>        if (stop_signal == TARGET_SIGNAL_TRAP && trap_expected)
> -       bpstat_clear (&stop_bpstat);
> +       {
> +         bpstat_clear (&stop_bpstat);
> +
> +         /* If we stepped into a delay slot, and the preceding instruction
> +            will be re-executed when resuming, step again before re-inserting
> +            the breakpoint.  */
> +         if (STEP_SKIPS_IN_DELAY_P
> +             && breakpoint_here_p (read_pc () - 2)
> +             && STEP_SKIPS_IN_DELAY (read_pc ()))
> +           ecs->another_trap = 1;
> +       }
>        else
>         {
>           /* See if there is a breakpoint at the current PC.  */
> 

I'm just not sure how this bit of logic should fit in.  I'm guessing its 
the second half of the state m/c sequence:

1. step off breakpoint at `PC'
2. step through delay

Andrew