Re: Non-stop debugging and automatically stopping the target

[Joel Brobecker <brobecker at adacore dot com>]

> 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