Re: [RFA] set/show enable-software-singlestep

[Michael Snyder <msnyder at specifix dot com>]

Any convergence on this?

On Wed, 2008-06-25 at 16:03 +0100, Pedro Alves wrote:
> A Wednesday 25 June 2008 15:42:15, Daniel Jacobowitz escreveu:
> > On Wed, Jun 25, 2008 at 03:14:38PM +0100, Pedro Alves wrote:
> > > A Wednesday 25 June 2008 14:34:57, Daniel Jacobowitz wrote:
> > > > I think it should already be auto.  can-use-software-singlestep is
> > > > unintuitive - either do use it, don't use it, or use GDB's best
> > > > judgement.  And if the user selects to use it and it isn't supported,
> > > > that's an error when we next want to singlestep.  WDYT?
> > >
> > > Well, not really auto.  If a ARM stub does software singlestepping itself
> > > (say we add it to gdbserver), gdb will still do software
> > > single-stepping (breakpoint dance), wont it?
> >
> > What Joel said elsewhere in the thread just now.  If we get a stub
> > that reports definitively that it can single step, that should take
> > priority over GDB knowing that software singlestep is implemented for
> > this architecture.
> >
> 
> What I said elsewhere in the thread just now.  :-)  The stub should
> report it, and a new target method is required, that takes precedence
> for stepping operations.
> 
> > Um, uh-oh.  This will break the overloading of software single step
> > for bypassing atomic operations.  Clearly more thought is required!
> >
> 
> The stub should just either step it all atomically, and GDB sees
> only one SIGTRAP, or we force continuing over the sequence with a
> single-step breakpoint (as we do today), not telling the
> stub to step at all (as we don't do today...).  We seems we need
> to distinguish this in the reporting mechanism.  Another issue is
> that the atomic operations bypassing is implemented inside
> the software_singlestepping gdbarch methods.  It should be
> factored out.
> 
> > Another unfortunate note: we can't trust the vCont reply for this even
> > though it's clearly the right thing :-(  Since current versions of GDB
> > reject replies without s/S.
> 
> Yep, I noticed that.  We'll need something else, probably
> qSupported (if we're thinking of supporting multi arch
> stubs, care must be taken here as well).
>