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

[Michael Snyder <msnyder@specifix.com>]

Silence equals assent?

On Mon, 2008-06-30 at 14:43 -0700, Michael Snyder wrote:
> 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).
> > 
>