Re: [PATCH 1/6] new observer command_option_changed.

[Yao Qi <yao@codesourcery.com>]

On Tuesday, July 24, 2012 02:38:52 PM Tom Tromey wrote:
> >>>>> "Yao" == Yao Qi <yao@codesourcery.com> writes:

Hi, Tom,
Thanks for the quick review.

> Yao> This patch is to add an extra field 'notify_observer_p' to identify
> Yao> the command will notify observer 'command_option_changed', and teach
> Yao> GDB to check the change of command option, and notify observer.
> 
> I read through the series to find out why this was needed.
> My understanding is that the idea is that options will be segregated
> into two kinds: those which report via the observer, and others; and
> that the decision is made in the gdb sources.
> 
> If that is accurate, I wonder if you could explain the rationale for it.
> Another possible design would be to report all option changes; or to let
> the MI client choose.

The general goal of my work is that "when the internal state of GDB is 
changed, and MI frontend and/or telnet session is not aware of the change, 
notify them to keep their display up to date".  For example, when user types 
command 'set $fp=0x1' in console, GDB should emit a MI notification to 
Eclipse, so that Eclipse can update its "register view" to show the latest 
value of $fp.  When user changes the option "set scheduler-locking step", and 
this change is interesting to Eclipse, GDB should emit a MI notification as 
well.

Not all the changes of GDB state are interesting to MI frontend.  As a subset 
of GDB state changes (other patch series in the future address other GDB state 
changes), not all the command option changes are interesting to MI frontend 
either, so it is not necessary to report all option changes.

> 
> The reason I ask is that making the decision statically seems tricky.
> When adding an option, what criteria do we use to decide?  How do we
> know what MI users want?  Or what if we want to add a Python hook

The criteria is "if Eclipse or other MI frontend needs to know the change of 
this command option, then we should report notification".  IMO, MI user should 
tell us what they want, and we can convert these commands from non-reporting 
to reporting.  Here is a list of commands that Marc Khouzam and I discussed 
offline, and we think they should be switched to reporting.  Note that this is 
not a full list, we may have other commands if needed.

   set circular-trace-buffer
   set disconnected-tracing
   set exec-direction
   set observer
   set may-insert-breakpoints (and the other may-*)
   set record
   set scheduler-locking
   set trace-notes (and other trace-*)
   set auto-solib-add

What do you mean by "add a Python hook"?  Is it something like "using an 
instance of gdb.Command to implement a new GDB CLI command"?  I know few on 
gdb python, but we may add extra parameter NOTIFY in 'Command.__init__', and 
notify command_option_changed observer somewhere.

> here -- maybe we would switch many more options over; but does switching
> an option from non-reporting to reporting cause issues for existing MI
> clients?  (I assume there is at least a bandwidth concern...)

AFAICS, the new MI notification "=option-changed" should not cause issues for 
existing MI clients.  In terms of bandwidth, every "=option-changed" is sent 
once user types command in console, user can't enter many commands at one 
moment (one command per second and ten commands at most, I think).  This 
notification should not occupy much bandwidth.

> What happens in the case where an option has a validation function that
> fails?  IIRC gdb has an internal design flaw here.
> 

If I understand you correctly, "validation function" means cli/cli-
setshow.c:parse_binary_operation and cli/cli-
setshow.c:parse_auto_binary_operation.  When validation fails, an error is 
thrown out, and observer is not called.

-- 
Yao (齐尧)