From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6485 invoked by alias); 4 Jan 2007 20:26:38 -0000 Received: (qmail 6472 invoked by uid 22791); 4 Jan 2007 20:26:38 -0000 X-Spam-Check-By: sourceware.org Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 04 Jan 2007 20:26:33 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1H2ZAP-0004Jy-Kv for gdb-patches@sources.redhat.com; Thu, 04 Jan 2007 23:26:30 +0300 Received: from localhost ([127.0.0.1] helo=ip6-localhost) by zigzag.lvk.cs.msu.su with esmtp (Exim 4.50) id 1H2ZAL-0004Jm-Rr; Thu, 04 Jan 2007 23:26:22 +0300 From: Vladimir Prus Subject: Re: [RFC] MI: Event notification To: Nick Roberts , gdb-patches@sources.redhat.com Date: Thu, 04 Jan 2007 20:26:00 -0000 References: <17817.40495.289353.14514@kahikatea.snap.net.nz> User-Agent: KNode/0.10.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit Message-Id: 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: 2007-01/txt/msg00133.txt.bz2 Nick Roberts wrote: > > This is another change based on Apple's work. It is part of my focus on > improving responsivity of the frontend, along with the timing patch. > > The general idea is to report changes in program state to the frontend so > that > it only updates the parts that need it. For example, after "up" > frame_changed_hook triggers and the frontend knows it has to update the > locals > display. You mean, after "up" emitted explicitly by the user? If the frontend changes the frame itself, it does not need any notifications. > This means that stepping through a single frame should be much > quicker. If GDB enters a new frame during execution, stack_changed_hook > triggers and the frontend knows it has to update the call stack display. > I would eventually like to add more hooks like target-changed-hook when > the user attaches to/detaches from a process, kills the process, or > selects a new target with the "file" command. Is this all for user-typed commands? I wonder if notifications for those are really needed. Reloading entire UI state after a user command does not seem too bad -- because user is not likely to enter 10 commands per second anyway -- and is much simpler. > The hooks are inserted/removed through "interpreter-exec console > cli-command" Sorry, can you clarify? > so I envisage not using MI commands like -exec-run, > -exec-next, -stack-select-frame that change that state. Again, what do you mean? - Volodya