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

["Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de>]

Sigh.

http://sources.redhat.com/ml/gdb-patches/2001-06/msg00383.html
http://sources.redhat.com/ml/gdb-patches/2001-06/msg00512.html
http://sources.redhat.com/ml/gdb-patches/2001-07/msg00001.html

will help figuring out the intent.

> On Aug 16,  3:26pm, Daniel Jacobowitz wrote:
> 
> > > 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.
> 
> I don't think so either.
> 
> Also, that magical value of 16 just can't be right for all architectures.
> 
> But this is one of those areas where we have to be *very* careful.
> We can attempt to make well-meaning changes and then discover many
> months later that we've broken something that used work.
> 
> For the above, I think we need to figure out the intent behind the
> condition
> 
>     INNER_THAN (read_sp (),(step_sp - 16),
> 
> and then write an architecture dependent method for it.
> 
> Kevin
> 
> 


-- 
Peter Schauer			pes@regent.e-technik.tu-muenchen.de