From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14675 invoked by alias); 16 Aug 2005 00:04:12 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 14455 invoked by uid 22791); 16 Aug 2005 00:03:18 -0000 Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 16 Aug 2005 00:03:18 +0000 Received: from farnswood.snap.net.nz (p177-tnt1.snap.net.nz [202.124.110.177]) by viper.snap.net.nz (Postfix) with ESMTP id ECF72688D95; Tue, 16 Aug 2005 12:03:13 +1200 (NZST) Received: by farnswood.snap.net.nz (Postfix, from userid 501) id 5597762A99; Tue, 16 Aug 2005 01:04:36 +0100 (BST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17153.11667.642470.761532@farnswood.snap.net.nz> Date: Tue, 16 Aug 2005 00:33:00 -0000 To: Bob Rossi Cc: Daniel Jacobowitz , gdb-patches@sources.redhat.com Subject: Re: RFC: MI output during program execution In-Reply-To: <20050815230511.GA10558@white> References: <17151.52148.262754.334426@farnswood.snap.net.nz> <20050815021546.GA20931@nevyn.them.org> <17152.6615.577337.131388@farnswood.snap.net.nz> <20050815230511.GA10558@white> X-SW-Source: 2005-08/txt/msg00188.txt.bz2 > What I offered to work on (because you mentioned you didn't have time), > is to improve the MI interface, by changing GDB's internals to alert > other parts of GDB (MI, maybe annotate=2,3) when certain conditions or > states have changed. For instance, breakpoints, frame's, threads, or > inferior state. I wasn't just a question of time, I don't currently have enough understanding of the code as a whole. I do know that there will be problems with threads, for example. Previous discussion on the mailing list has shown that GDB loses track of the selected frame when the thread is changed back and forth. Also variable objects don't record the thread for which they were created. > By doing this, the MI layer can then check to see what has changed after > each command is run, including -interpreter-exec console commands. The > MI layer can then issue data to the FE depending on what has changed, > and potentially what the FE requested for changes. > > This might require changing the MI output syntax to add a new section > for changes like above. I'm not sure about this yet. > > Does this proposed solution sound reasonable to you? Will this solve all > the needs that you have? To be honest, CGDB also won't work without > these changes. However, with theses changes, MI might be getting close > to being very usable, thus, deprecating annotations. Do you agree? I poll GDB to get the state after every command. This might be slower but it's generally workable. On the other hand, I can't find out if the inferior is running or not when a CLI command is executed. I don't think that your proposed changes will solve this problem. > To be realist, I expect these changes to take several months. Especially > since Mark Kettenis asked that all the deprecated functions be removed > first. Hopefully the time won't be an issue. More like several years I would think! The location of the deprecated functions in the code tells you where notification should take place. I would remove these once you have your code working. This presumably also provides a fallback position. Nick