This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]