Software-vs-hardware single-step vs. sim/non-sim targets.

Software-vs-hardware single-step vs. sim/non-sim targets.

[Dave Korn]

    Hi all,

  I have a GDB port for a custom target, a sim-based simulator, and a gdbstub
for use on the real thing.  GDB can single step the simulator of course, since
the support for simulated hardware-single-step is built in, but I'd like to
save bytes in the gdbstub by not implementing support for the "s" command.

  So is there a way I can get gdb to use (simulated) hardware single stepping
for the simulator target and software single stepping for the remote target?
And dynamically switch when the target changes?  Or do I have to compile two
different builds, only one of which sets the software single step method in
the gdbarch?

  I'm trying not to do anything too hacky or break the architectural layering
in GDB, but can I perhaps examine the current_target in my arch init function
and frig the value of the single_step hook in the gdbarch that I either lookup
or allocate before returning it?  Does the arch init function always get
called when switching between targets or otherwise altering the layers in the
stratum stack?

    cheers,
      DaveK

Re: Software-vs-hardware single-step vs. sim/non-sim targets.

[Daniel Jacobowitz]

On Fri, Dec 04, 2009 at 09:14:40PM +0000, Dave Korn wrote:
>   So is there a way I can get gdb to use (simulated) hardware single stepping
> for the simulator target and software single stepping for the remote target?
> And dynamically switch when the target changes?  Or do I have to compile two
> different builds, only one of which sets the software single step method in
> the gdbarch?
> 
>   I'm trying not to do anything too hacky or break the architectural layering
> in GDB, but can I perhaps examine the current_target in my arch init function
> and frig the value of the single_step hook in the gdbarch that I either lookup
> or allocate before returning it?  Does the arch init function always get
> called when switching between targets or otherwise altering the layers in the
> stratum stack?

Answering the last question first, no, it does not necessarily get called.

There's no obvious easy solution to this, but the basic problem has
been discussed many times.  It's gotten more complicated since I last
thought about it, too, by the addition of support for software
stepping atomic sequences.  There are several mixed-up questions:

(SSS = software single-step; got tired of typing it.)

* Does my architecture code support SSS for anything?

* Does my architecture require SSS for the current instruction or
instruction sequence?

* Does my target support hardware single-step?

IMO the remote protocol hook you need is already present: implement
vCont, even though it's overkill for an embedded single-threaded
processor.  Report that you don't support s or S in the vCont? reply.

Current GDB will choke.  So you have to somehow separate the above
questions, so that when we ask the architecture whether to
single-step, it knows whether the target needs SSS or not.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Software-vs-hardware single-step vs. sim/non-sim targets.

[Dave Korn]

Daniel Jacobowitz wrote:

[ out-of-order:
> There's no obvious easy solution to this, but the basic problem has
> been discussed many times.

  Sorry for making you go over old ground; it's not easy to get good search
results with terms as general as "hardware software single step gdb"; I
wouldn't be offended if you replied with just a couple of words for better
search terms or URLs to earlier threads. ]

> Answering the last question first, no, it does not necessarily get called.

> IMO the remote protocol hook you need is already present: implement
> vCont, even though it's overkill for an embedded single-threaded
> processor.  Report that you don't support s or S in the vCont? reply.
> 
> Current GDB will choke.  So you have to somehow separate the above
> questions, so that when we ask the architecture whether to
> single-step, it knows whether the target needs SSS or not.

  Hmm, okay, so the arch doesn't get re-inited between detaching from one
target and attaching to the next.  But I'd bet (and I mean bet, I haven't
looked yet, but I can't imagine how the whole thing hangs together if it
doesn't work this way) that the infrun state machine does get thoroughly and
properly reset and all in-memory breakpoints restored during the
detach/reattach sequence.  So in theory it should all be ok if
gdbarch_software_single_step_p() returned different values dynamically, so
long as they're constant during any given run of the inferior.  Maybe it would
work to turn that into an arch hook, with a default that works like the
current version by simply testing if the single_step hook is set, but allow
for a dynamically-varying version to be installed by arches that choose.  I'll
look a bit at how well that would work.

  (Ah, gdbarch_software_single_step_p makes an instructive search term, there
seems to have been some discussion about what to do round the time when the
macro version got replaced by a hook.  Haven't yet found anything that looks
like a firm resolution to it though.)

    cheers,
      DaveK

Re: Software-vs-hardware single-step vs. sim/non-sim targets.

[Daniel Jacobowitz]

On Sat, Dec 05, 2009 at 04:05:52AM +0000, Dave Korn wrote:
> detach/reattach sequence.  So in theory it should all be ok if
> gdbarch_software_single_step_p() returned different values dynamically, so
> long as they're constant during any given run of the inferior.  Maybe it would

gdbarch_software_single_step_p can be completely inconsistent
nowadays; that's how stepping atomic sequences work.  You step those
but not other instructions.

-- 
Daniel Jacobowitz
CodeSourcery

RE: Software-vs-hardware single-step vs. sim/non-sim targets.

[Jakob Engblom]

>   I have a GDB port for a custom target, a sim-based simulator, and a gdbstub
> for use on the real thing.  GDB can single step the simulator of course, since
> the support for simulated hardware-single-step is built in, but I'd like to
> save bytes in the gdbstub by not implementing support for the "s" command.

Can't you just use gdb-serial as the level of intermediation?

And hide all implementations behind a common facade, and use a single standard
gdb as the front-end?


/jakob