[RFA] gdb-events.sh: selected-frame-level-changed event

[RFA] gdb-events.sh: selected-frame-level-changed event

[Keith Seitz]

Hi,

MI uses GDB's frame level to track a user's view of the current stack. As 
you can imagine, this is tightly coupled to the console's stack commands 
("up", "down", and "frame").

This event notifies clients when the stack frame level has been changed, 
allowing all the UIs to remain in sync wrt the stack view.

I'll submit the stack.c changes separately, since the exact meaning
of this event may be open to interpretation.

Keith

ChangeLog
2002-08-22  Keith Seitz  <keiths@redhat.com>

        * gdb-events.sh: Add selected-frame-level-changed event.
        * gdb-events.c: Regenerated.
        * gdb-events.h: Regenerated.

Patch
Index: gdb-events.sh
===================================================================
RCS file: /cvs/src/src/gdb/gdb-events.sh,v
retrieving revision 1.14
diff -p -r1.14 gdb-events.sh
*** gdb-events.sh	21 Aug 2002 15:34:36 -0000	1.14
--- gdb-events.sh	22 Aug 2002 18:17:36 -0000
*************** f:void:tracepoint_delete:int number:numb
*** 66,71 ****
--- 66,72 ----
  f:void:tracepoint_modify:int number:number
  f:void:architecture_changed:void
  f:void:target_changed:void
+ f:void:selected_frame_level_changed:int level:level
  #*:void:annotate_starting_hook:void
  #*:void:annotate_stopped_hook:void
  #*:void:annotate_signalled_hook:void
*************** f:void:target_changed:void
*** 88,94 ****
  #*:void:readline_begin_hook:char *format, ...:format
  #*:char *:readline_hook:char *prompt:prompt
  #*:void:readline_end_hook:void
- #*:void:context_hook:int num:num
  #*:int:target_wait_hook:int pid, struct target_waitstatus *status:pid, status
  #*:void:call_command_hook:struct cmd_list_element *c, char *cmd, int from_tty:c, cmd, from_tty
  #*:NORETURN void:error_hook:void:: ATTR_NORETURN
--- 89,94 ----

Re: [RFA] gdb-events.sh: selected-frame-level-changed event

[Andrew Cagney]

> Hi,
> 
> MI uses GDB's frame level to track a user's view of the current stack. As 
> you can imagine, this is tightly coupled to the console's stack commands 
> ("up", "down", and "frame").
> 
> This event notifies clients when the stack frame level has been changed, 
> allowing all the UIs to remain in sync wrt the stack view.
> 
> I'll submit the stack.c changes separately, since the exact meaning
> of this event may be open to interpretation.

Ok.

Any thoughts on how selected-thread events will be handled?  They also 
change the selected-fraome.

Andrew

Re: [RFA] gdb-events.sh: selected-frame-level-changed event

[Keith Seitz]

On Sun, 25 Aug 2002, Andrew Cagney wrote:

> Ok.

Committed.

> Any thoughts on how selected-thread events will be handled?  They also 
> change the selected-fraome.

I think that like many events, selected-thread change events imply that a 
whole bunch of things have changed, too. For example, a target-stop event 
(which we don't really issue as an event like the rest, but it is really 
just an event), automatically implies that the selected frame, thread, and 
other things have changed, yet we do not issue events for all of these. I 
believe that the selected-thread event is the same.

In any case, I'm sure that we've done things wrong. In fact, I'd be 
willing to bet that we have. But one small step forward is better than 
none. We can always address issues as they appear, which is one of the 
nice things about the event mechanisms: GDB itself doesn't use them! They 
are UI-specific and quite isolated. :-)

Keith

Re: [RFA] gdb-events.sh: selected-frame-level-changed event

[Andrew Cagney]

> On Sun, 25 Aug 2002, Andrew Cagney wrote:
> 
> 
>> Ok.
> 
> 
> Committed.


BTW, like any MI change, documentation and a testcase are also needed.

>> Any thoughts on how selected-thread events will be handled?  They also 
>> change the selected-fraome.
> 
> 
> I think that like many events, selected-thread change events imply that a 
> whole bunch of things have changed, too. For example, a target-stop event 
> (which we don't really issue as an event like the rest, but it is really 
> just an event), automatically implies that the selected frame, thread, and 
> other things have changed, yet we do not issue events for all of these. I 
> believe that the selected-thread event is the same.

GDB doesn't issue a target-stop event because it isn't possible to go 
back to GDB and ask it why it stopped.  The stop message is generated on 
the fly --- known bug in current implementation :-(

> In any case, I'm sure that we've done things wrong. In fact, I'd be 
> willing to bet that we have. But one small step forward is better than 
> none. We can always address issues as they appear, which is one of the 
> nice things about the event mechanisms: GDB itself doesn't use them! They 
> are UI-specific and quite isolated. :-)

We need to be careful though.  Otherwize GDB will be locked into 
supporting something broken for the next N years :-(


Andrew

Re: [RFA] gdb-events.sh: selected-frame-level-changed event

[Keith Seitz]

On Mon, 26 Aug 2002, Andrew Cagney wrote:

> BTW, like any MI change, documentation and a testcase are also needed.

It doesn't change MI. CVS head MI doesn't even use events. Right now, 
the only official user is Insight (which reminds me, I have yet to check 
in changes for Insight to deal with these new events!).

I have patches in the interpreter branch which will change MI to using 
gdb-events, and I have the corresponding documentation there, as 
well. Just waiting for review of interps.[ch] to get this all going.

> GDB doesn't issue a target-stop event because it isn't possible to go 
> back to GDB and ask it why it stopped.  The stop message is generated on 
> the fly --- known bug in current implementation :-(

Yeah, but it's close enough! :-)

> We need to be careful though.  Otherwize GDB will be locked into 
> supporting something broken for the next N years :-(

I think that we can be a little finnicky about this. While UIs written on 
top of MI may like it if we never change anything for a very long time, 
well, I don't think we need to feel that we have any obligation to carry 
around legacy code like this. We've certainly never heard from anyone but 
Apple (and I guess Mo is doing something with MI), and Apple is certainly 
capable of dealing with these changes.

:-) Besides people will get little sympathy from me. Just look at the 
history of how some of the most innocent gdb changes have completely 
broken Insight! :-)

Seriously, though, I applaud your chivalry on this subject, but interfaces 
develop and "libraries" change. We're no different than, eg. readline, and 
how often have we updated gdb to use the latest readline?

Keith