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

[Pedro Alves <pedro@codesourcery.com>]

Hi Michael,

Sorry for the silence,

On Thursday 10 July 2008 03:46:10, Michael Snyder wrote:
> Silence equals assent?

I had understood the consensus was that the command would be
useful for now.

It would be really nice if someone that had a target that
always required disabling software-singlestepping stepped forward
to add the GDB/remote smarts to do it automatically, though.  ;-)

>
> 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).



-- 
Pedro Alves