This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 1/6] new observer command_option_changed.
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 (éå)