Non-stop debugging and automatically stopping the target

[Daniel Jacobowitz <drow@false.org>]

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