Re: [RFA] enable software single step on alpha-osf

[Daniel Jacobowitz <drow at mvista dot com>]

On Fri, Aug 16, 2002 at 03:11:02PM -0400, Andrew Cagney wrote:
> 
> >So, to summarize: 
> >
> >  1 - The change "+           stop_pc -= DECR_PC_AFTER_BREAK;" seems
> >      to be going in the right direction.
> >
> >  2 - However I should hold this change for now because you think I should
> >      write the adjusted PC value back to the target, by adding something
> >      like "write_pc_pid (stop_pc, ecs->ptid)"
> >
> >      I will verify the impact of such a change, and report.
> >    
> >  3 - Assuming we get all issues in this RFA resolved, then I will start
> >      looking at the addition of the software_singlestep flag.
> 
> I think the flag should be added as part of the change.  That way we're 
> 100% certain that bpstat_stop_status() isn't going to do a 
> decr_pc_after_break.
> 
> Expressions like:
> 
> /* Pass TRUE if our reason for stopping is something other
>    than hitting a breakpoint.  We do this by checking that
>    1) stepping is going on and 2) we didn't hit a breakpoint
>    in a signal handler without an intervening stop in
>    sigtramp, which is detected by a new stack pointer value
>    below any usual function calling stack adjustments.  */
> (currently_stepping (ecs)
>  && prev_pc != stop_pc - DECR_PC_AFTER_BREAK
>  && !(step_range_end && INNER_THAN (read_sp (),(step_sp - 16)))));

Which reminds me - does that use of INNER_THAN make even the slightest
sense on stack-grows-up architectures?  I don't think it does.

> would be changed to read:
> 
> (trap_was_a_software_singlestep
>  || ....)
> 
> Hmm, looking at the above, on an architecture like the i386, the test 
> ``prev_pc != stop_pc - DECR_PC_AFTER_BREAK'' is probably false when if 
> the code has just stepped off a single byte instruction :-(

Is there some way we can do this without growing that condition?  It's
awful, and it makes very little sense; it feels like something that
should already have been handled.

Yes, I'm trying to trick Joel into doing some of the
DECR_PC_AFTER_BREAK cleanups that everyone keeps meaning to do.  It's
just not being handled somewhere useful right now.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer