The main event(s)...

The main event(s)...

[Keith Seitz]

Hi,

Well, I think we're at the point where we need to really start cleaning up
Insight.

Fernando has already started a plugin class (thanks Fernando!), and it
occurred to me while looking over the code: It isn't at all obvious
what events are communicated from gdb to Insight.

In an effort to identify these events, I would like to propose the following
cleanup:

Currently, windows/widgets register for events from gdb by using "add_hook".
For example, to register with the GUI what to do when the target's state
has changed (stopped executing or a stack frame change by the user), windows
would do something like this:

     FooWindow::constructor {args} {
        # ...
        add_hook gdb_update_hook [code $this update]
        # ...
      }

     FooWindow::destructor {args} {
        # ...
        remove_hook gdb_udate_hook [code $this update]
        # ...
     }

My proposal is to whack all occurences of "add_hook" (and 
"remove_hook") and just extend GDBWin (a now empty class) to include a 
dispatch method for events. (I think that GDBWin was originally "written" 
with this idea in mind.) Every window interested in gdb events would 
inherit from GDBWin. Then, to "register" for an event, simply override the 
GDBWin method. So, assuming we use "update" as the method name for what we 
currently call gdb_update_hook, we would have:

     FooWindow::update {args} {
       # code for updating
     }

Events would come from gdb in the normal way, except instead of
doing:

     proc gdbtk_tcl_foo_event {args} {
        set err [catch {run_hooks foo_hook} txt]
        # blah blah
     }

We would simply have:

     proc gdbtk_tcl_foo_event {args} {
       GDBWin::dispatch foo $args
     }

(Yes, would could even call this directly from the hook in C-land.)

In the process, this would give all windows access to all event
notification, and give us "one" file (gdbwin.ith/b) which defined
all known events.

Comments? (Yes, I have an incomplete prototype working if you need/want
to see more details.)

Keith

Re: The main event(s)...

[Martin M. Hunt]

I think this is something we should have done long ago.

Maritn


On Thu, 22 Feb 2001, Keith Seitz wrote:

> Hi,
>
> Well, I think we're at the point where we need to really start cleaning up
> Insight.
>
> Fernando has already started a plugin class (thanks Fernando!), and it
> occurred to me while looking over the code: It isn't at all obvious
> what events are communicated from gdb to Insight.
>
> In an effort to identify these events, I would like to propose the following
> cleanup:
>
> Currently, windows/widgets register for events from gdb by using "add_hook".
> For example, to register with the GUI what to do when the target's state
> has changed (stopped executing or a stack frame change by the user), windows
> would do something like this:
>
>      FooWindow::constructor {args} {
>         # ...
>         add_hook gdb_update_hook [code $this update]
>         # ...
>       }
>
>      FooWindow::destructor {args} {
>         # ...
>         remove_hook gdb_udate_hook [code $this update]
>         # ...
>      }
>
> My proposal is to whack all occurences of "add_hook" (and
> "remove_hook") and just extend GDBWin (a now empty class) to include a
> dispatch method for events. (I think that GDBWin was originally "written"
> with this idea in mind.) Every window interested in gdb events would
> inherit from GDBWin. Then, to "register" for an event, simply override the
> GDBWin method. So, assuming we use "update" as the method name for what we
> currently call gdb_update_hook, we would have:
>
>      FooWindow::update {args} {
>        # code for updating
>      }
>
> Events would come from gdb in the normal way, except instead of
> doing:
>
>      proc gdbtk_tcl_foo_event {args} {
>         set err [catch {run_hooks foo_hook} txt]
>         # blah blah
>      }
>
> We would simply have:
>
>      proc gdbtk_tcl_foo_event {args} {
>        GDBWin::dispatch foo $args
>      }
>
> (Yes, would could even call this directly from the hook in C-land.)
>
> In the process, this would give all windows access to all event
> notification, and give us "one" file (gdbwin.ith/b) which defined
> all known events.
>
> Comments? (Yes, I have an incomplete prototype working if you need/want
> to see more details.)
>
> Keith
>
>

Re: The main event(s)...

[Andrew Cagney]

Keith Seitz wrote:
> 
> Hi,
> 
> Well, I think we're at the point where we need to really start cleaning up
> Insight.
> 
> Fernando has already started a plugin class (thanks Fernando!), and it
> occurred to me while looking over the code: It isn't at all obvious
> what events are communicated from gdb to Insight.
> 
> In an effort to identify these events, I would like to propose the following
> cleanup:
> 
> Currently, windows/widgets register for events from gdb by using "add_hook".
> For example, to register with the GUI what to do when the target's state
> has changed (stopped executing or a stack frame change by the user), windows
> would do something like this:

Two comments:

	o	one day, gdb really will become
		async.  at that point the basic
		assumption that target_running
		== !target_not_running will
		go out the window.

		While I'd ignore this for now
		just keep it in mind.

	o	the way GDB feeds events up
		to insight is pretty bogus

		If you can, try to figure out
		some generic operations
		so that gdb can feed them up
		(rather than the current
		really really specific events)

		Rather than wait for GDB to
		do this for you, could I suggest
		creating a layer that sits
		between GDB and INSIGHT and
		have that massage the current
		events into something more
		meaningful.

		That should avoid the problem
		of INSIGHT constantly wanting
		to change the event hooks
		in GDB.

Andrew

Re: The main event(s)...

[Fernando Nasser]

Andrew Cagney wrote:
> 
>                 Rather than wait for GDB to
>                 do this for you, could I suggest
>                 creating a layer that sits
>                 between GDB and INSIGHT and
>                 have that massage the current
>                 events into something more
>                 meaningful.
> 

That is already done.  GDB hooks (events) are transformed into Insight
hooks (events) by the "interface.tcl" code.  The choice of events (on
both sides) are not very good at the moment and can be improved.

>                 That should avoid the problem
>                 of INSIGHT constantly wanting
>                 to change the event hooks
>                 in GDB.
> 

If a proper study is performed once, the set of events is bound to last
almost with no changes.  The problem now is that the events were created
ad hoc.

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: The main event(s)...

[Keith Seitz]

On Fri, 23 Feb 2001, Steven Johnson wrote:

> Would this mean that a plugin could hook events and send commands to
> GDB? 
> (Which I believe it can not do now safely.)

This would allow any window which inherited from GDBWin access to any 
event from gdb (or from the gui). As it currently stands, PluginWindow 
registers only three events:

. idle
. busy
. no_inferior

Note that this does not exclude the individual plugins from registering 
from any other events. It's just not obvious what those other events are!

As for sending commands to gdb, yes, when the inferior is not running, 
windows/plugins may send commands to gdb. Note that the use of gdb_cmd 
and gdb_immediate (which simulate command-line input) are now deprecated. 

Keith