Non-stop debugging and automatically stopping the target

Non-stop debugging and automatically stopping the target

[Daniel Jacobowitz]

This is a followup to Nick's backtrace patch of April 1st, which
temporarily stops the target to generate a backtrace.  It raises an
issue which Pedro and Volodya have also noticed, and I think we should
discuss it before we commit to any option.  The general issue is
this: should GDB implicitly stop the target?

For instance, consider memory reads.  Reading memory while the target
is running divides roughly into these types:

  - Can't do it.  GDB has to stop the target first.  Reading memory
    via ptrace is in this category.

  - Can do it, mildly intrusively (5ms - 10ms delay in execution).
    Some embedded debug interfaces are like this; the CPU is used to
    assist the debug interface, so while it's processing debug
    requests the target does not make progress.

  - Can do it, as long as some other thread is stopped.  Ptrace on a
    multi-threaded program is in this category, generally.  It doesn't
    matter which thread is stopped.

  - Can do it, pretty much transparently to the target.  Some embedded
    debug interfaces are like this; so is reading memory via /proc
    on a multi-processor Linux system.

Then of course there are race conditions.  Even if we can read memory
non-intrusively, we probably can't get a consistent snapshot of memory
for long enough to generate a backtrace; the current function will
return in the middle of the unwinding process.  So for backtrace, the
target is going to have to stop.

Under which of these conditions should we allow the user to say
"backtrace" or "x/x ADDR", and under which should we require the user
(or front end) to say "stop thread 3; backtrace; continue thread 3"?
I am a little worried about making backtrace always work even if it
has to pause the target; some targets should not be paused without
explicit request, if they're time sensitive.  Or maybe time-sensitive
should be a setting the user or front end has to make.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Non-stop debugging and automatically stopping the target

[Joel Brobecker]

> The general issue is this: should GDB implicitly stop the target?

I think some commands are more "special" than others, and indeed
backtrace is one of those.

> Then of course there are race conditions.  Even if we can read memory
> non-intrusively, we probably can't get a consistent snapshot of memory
> for long enough to generate a backtrace; the current function will
> return in the middle of the unwinding process.  So for backtrace, the
> target is going to have to stop.

Yes, I don't see a way out of stopping the inferior if we want to be
able to reliably compute the backtrace. But even for plain memory reads
(such as "x/x ADDR" or just plain "print VAR"), there are also possible
race conditions.

The subject of this thread says "non-stop" mode, so does it mean that
in "all-stop" mode we're assuming that the target program is not time-
sensitive, and so we'll always pause it? In which case, I assume users
of the "non-stop" mode are in fact worried about time spent in suspended
mode. I think it's important to understand who are going to be the typical
users of the non-stop mode.

Assuming I am correct about the distinction, we could decide that
all these commands (backtrace, x, etc) do in fact implicitly interrupt
the inferior when in all-stop mode.

If the typical user of the non-stop mode is in fact worried about
not affecting the timing of his application, I allow most commands
that we expect to be processed quickly (print VAR, x/x, etc) to be
performed while running if the target allows it - knowing that the
output could be corrupted if the target was writing the data we're
reading at the same time. For the backtrace, I'm unsure. We could
try experimenting with NOT stopping the target and see if we can
make it produce something correct at least a decent proportion of
the time.

I don't see any problem with disallowing the backtrace command in
non-stop mode, or making it implicitly stop the target (in that
case, I would suggest the use of an option to protect its use).

Requiring that the user suspend the target himself in order to being
able to get a backtrace is not that attractive, IMO. In that case,
the user would have to perform a sequence of 3 steps (suspend;
backtrace; resume) instead of just one command, which would probably
take more time than if the backtrace command did the suspend/resume
itself.

-- 
Joel

Re: Non-stop debugging and automatically stopping the target

[Daniel Jacobowitz]

On Thu, Apr 10, 2008 at 10:41:24AM -0700, Joel Brobecker wrote:
> The subject of this thread says "non-stop" mode, so does it mean that
> in "all-stop" mode we're assuming that the target program is not time-
> sensitive, and so we'll always pause it?

I just wasn't thinking about the problem properly.  Nick's subject
was right; this applies to any async target.

Perhaps there should be a "real-time sensitive" setting, then -
probably off by default with a nice manual section?

-- 
Daniel Jacobowitz
CodeSourcery

Re: Non-stop debugging and automatically stopping the target

[Joel Brobecker]

> Perhaps there should be a "real-time sensitive" setting, then -
> probably off by default with a nice manual section?

That sounds like a plan to me.

What would we do if the setting was on, though?
  - disallow backtrace?
  - allow memory reads?

-- 
Joel