From mboxrd@z Thu Jan  1 00:00:00 1970
From: Keith Seitz <keiths@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: <gdb@sources.redhat.com>
Subject: Re: [RFC] Inferior stop events
Date: Thu, 14 Jun 2001 08:13:00 -0000
Message-id: <Pine.GSO.4.33.0106140802230.27055-100000@makita.cygnus.com>
References: <Pine.SUN.3.91.1010614110036.972L-100000@is>
X-SW-Source: 2001-06/msg00120.html

On Thu, 14 Jun 2001, Eli Zaretskii wrote:

> For the benefit of the GUI-challenged people such as myself: how, if at
> all, is this done now?  That is, what does a typical UI for GDB do to
> tell the user why did the debuggee stopped?

I can only speak for Insight. We use the call_command_hook, and we assume
that the target will run if the command's class is class_run or
class_trace.

Before calling the actual function bound to the command, we run a script
to tell the rest of the UI that we are about to be "busy". When the
command is done (and the function returns), we tell the UI that it is
idle. This tells us that gdb is no longer using the inferior, but it does
not tell us what happened. Did it exit? Hit a breakpoint? Take a signal?

Mind you, some of these things we can sort of figure out. For example,
when the inferior gets a signal, we have a hook which runs in the global
context. At one time, we attempted to parse the output of "info targ". All
kinds of nasty things. IMO this is much cleaner.

Hope this helps.
Keith