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

[Pedro Alves <pedro at codesourcery dot com>]

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