From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8699 invoked by alias); 25 Jul 2012 03:56:56 -0000 Received: (qmail 8691 invoked by uid 22791); 25 Jul 2012 03:56:55 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 25 Jul 2012 03:56:42 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1StsiG-0006tn-R8 from Yao_Qi@mentor.com ; Tue, 24 Jul 2012 20:56:40 -0700 Received: from SVR-ORW-FEM-03.mgc.mentorg.com ([147.34.97.39]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 Jul 2012 20:56:40 -0700 Received: from qiyao.dyndns.org (147.34.91.1) by svr-orw-fem-03.mgc.mentorg.com (147.34.97.39) with Microsoft SMTP Server id 14.1.289.1; Tue, 24 Jul 2012 20:56:39 -0700 From: Yao Qi To: CC: Tom Tromey Subject: Re: [PATCH 1/6] new observer command_option_changed. Date: Wed, 25 Jul 2012 03:56:00 -0000 Message-ID: <1452365.122ECxjKta@qiyao.dyndns.org> User-Agent: KMail/4.8.3 (Linux/3.3.7-1.fc16.i686; KDE/4.8.3; i686; ; ) In-Reply-To: <87394gopwj.fsf@fleche.redhat.com> References: <1343146252-22558-1-git-send-email-yao@codesourcery.com> <1343146252-22558-2-git-send-email-yao@codesourcery.com> <87394gopwj.fsf@fleche.redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-07/txt/msg00512.txt.bz2 On Tuesday, July 24, 2012 02:38:52 PM Tom Tromey wrote: > >>>>> "Yao" =3D=3D Yao Qi 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. >=20 > 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. >=20 > 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=20 changed, and MI frontend and/or telnet session is not aware of the change,= =20 notify them to keep their display up to date". For example, when user type= s=20 command 'set $fp=3D0x1' in console, GDB should emit a MI notification to=20 Eclipse, so that Eclipse can update its "register view" to show the latest= =20 value of $fp. When user changes the option "set scheduler-locking step", a= nd=20 this change is interesting to Eclipse, GDB should emit a MI notification as= =20 well. Not all the changes of GDB state are interesting to MI frontend. As a subs= et=20 of GDB state changes (other patch series in the future address other GDB st= ate=20 changes), not all the command option changes are interesting to MI frontend= =20 either, so it is not necessary to report all option changes. >=20 > 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 o= f=20 this command option, then we should report notification". IMO, MI user sho= uld=20 tell us what they want, and we can convert these commands from non-reportin= g=20 to reporting. Here is a list of commands that Marc Khouzam and I discussed= =20 offline, and we think they should be switched to reporting. Note that this= is=20 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=20 instance of gdb.Command to implement a new GDB CLI command"? I know few on= =20 gdb python, but we may add extra parameter NOTIFY in 'Command.__init__', an= d=20 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 "=3Doption-changed" should not cause issues= for=20 existing MI clients. In terms of bandwidth, every "=3Doption-changed" is s= ent=20 once user types command in console, user can't enter many commands at one=20 moment (one command per second and ten commands at most, I think). This=20 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. >=20 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= =20 thrown out, and observer is not called. --=20 Yao (=E9=BD=90=E5=B0=A7)