From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30019 invoked by alias); 29 Sep 2004 17:27:57 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 30005 invoked from network); 29 Sep 2004 17:27:53 -0000 Received: from unknown (HELO lakermmtao07.cox.net) (68.230.240.32) by sourceware.org with SMTP; 29 Sep 2004 17:27:53 -0000 Received: from white ([68.9.64.121]) by lakermmtao07.cox.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20040929172753.CLAT20766.lakermmtao07.cox.net@white>; Wed, 29 Sep 2004 13:27:53 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1CCiF6-0000KR-00; Wed, 29 Sep 2004 13:27:52 -0400 Date: Wed, 29 Sep 2004 17:27:00 -0000 From: Bob Rossi To: Jim Ingham Cc: gdb@sources.redhat.com Subject: Re: MI rules Message-ID: <20040929172752.GA1054@white> Mail-Followup-To: Jim Ingham , gdb@sources.redhat.com References: <1095954341.19418.ezmlm@sources.redhat.com> <20040925010519.GB3379@white> <4E6C7AD8-0F25-11D9-AD7A-000D932CB92C@apple.com> <20040925201242.GA4133@white> <1AB1A5F6-10AC-11D9-8F3A-000A958F4C44@apple.com> <20040929025959.GA357@white> <879F6C54-1232-11D9-A48C-00039379E320@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <879F6C54-1232-11D9-A48C-00039379E320@apple.com> User-Agent: Mutt/1.3.28i X-SW-Source: 2004-09/txt/msg00257.txt.bz2 Hi Jim, Thanks again for taking the time to discuss this with me. On Wed, Sep 29, 2004 at 09:13:41AM -0700, Jim Ingham wrote: > Bob, > > First, I think parts of the discussion are unclear because you are a > little lax on terminology. What you are calling asynchronous COMMANDS > are really asynchronous NOTIFICATIONS. They aren't the result of a > command, but something that happens in gdb that gdb decides it ought to > tell you about. There are actually different mechanisms to emit them > in gdb, so they are clearly separated in the code. OK, understood that there is some miscommunication. I refer to all output commands as MI output commands, if they are asyncronous or not. I picked this terminology up from the manual at 24.1.2 GDB/MI Output Syntax. The async-record is in particular what I mean when I say asyncronous and it is part of an MI output command. I believe that at least these asyncronous MI output commands need to have a tag in order for the front end to undestand what kind of MI output command ( asyncronous notification ) is being sent from GDB. > And yes, ALL asynchronous notifications need to be tagged. I haven't > played around with TOT without our modifications, so I can't actually > tell you what the state is there, but if this isn't the case it > certainly ought to be. I would be surprised if they weren't, but... The tag is not in the grammer. So, if it is actually outputted by GDB then I would be very happy because just the grammer needs to be updated. However, if it the grammer is correct, I need this in the mainline GDB to get some reasonable work done. I would be happy to work on the implemenation, unless of course you already have a patch that does just what I need. > About incompatible changes. I see the need to have a stable version of > the MI so that you can deliver a front end that will work with some > reasonable range of gdb's. OTOH, putting a whole lot of effort into > making your front end work with every possible variant of the > development versions of the MI seems to me like a misdirection of our > limited resources. The current state falls short of your needs right > now because you need to use the development version only, and until > that is stable, you are in a bind. But over designing for a side > effect of the software not being all the way done is not as good a use > of resources as actually getting a stable version that has what you > need... I understand what you are saying. Unfortunatly the reality is that many major distributions ( debian ) take a snapshot of GDB, instead of waiting for a major release. Because of this, front ends would not work out of the box on normal distributions. This seems unreasonable. > The thing I think we really need to work on (besides tagging > notifications if there is any place they aren't tagged) is making the > command INPUT more robust. The output is already pretty good, there is > seldom a need to remove fields, and adding fields is done in a way that > the client can handle. But the command input is not similarly > self-labeling, and thus much more fragile. I am very willing to work on the MI input commands. I'm sure I'll be making a lot of noise when I get to that point. However, I haven't even gotten to that point because I am trying to design and implement the parsing of the MI output commands. Until I can get that working properly, I can't even think about the input commands. > > Jim > > On Sep 28, 2004, at 7:59 PM, Bob Rossi wrote: > > >I have one quick note. I would prefer to get some cooperation with the > >MI maintainers. I seriously need this cooperation in order to get > >anything done with CGDB. Also, I consider the work I am doing necessary > >for any front end developer to be able to write a reasonable front end > >without having to heavily patch a version of GDB they distribute with. > > > >If you consider my goal worthy, please at least respond with some > >reasonable criticism so that these issues can be resolved. I feel that > >in > >many ways my views on the MI are mostly ignored by the MI maintainers. > >I would like to improve GDB in the areas that seem relevant to front > >end > >developers and am assuming that you all have the same goal. So > >hopefully these issues and the ones in the future can be resolved > >within > >a reasonable amount of time. > > > > > >On Mon, Sep 27, 2004 at 10:38:55AM -0700, Jim Ingham wrote: > >> > >>On Sep 25, 2004, at 1:12 PM, Bob Rossi wrote: > >> > >>>On Sat, Sep 25, 2004 at 12:01:28PM -0700, Jim Ingham wrote: > >>>>I have no strong opposition to this, I just don't see the point. > >>>> > >>> > >>>Jim, I appreciate the time you have spent thinking about this issue > >>>for > >>>me. I value the input from someone who has been working with MI for > >>>quite some time. I have several questions for you, > >>> > >>> 1. How do you figure out what type of asynchronous MI output > >>>command > >>> you just received is? > >> > >>There are two things here - there is asynchronous output from an MI > >>command, like stopped, running, etc. We added "running breakpoint > >>command message so you can tell that it might start up again..." This > >>sort of thing - usually from running. They are always linked to the > >>original command by preserving the command token. So that's easy. > >> > >>Then there is true asynchronous communications from the inferior - > >>unsolicited messages like shared library notification, or the fact > >>that > >>a user command ("interpreter-exec") caused a breakpoint to be set, the > >>thread or the frame to be changed, etc... These are all dealt with > >>just as you suggest for commands - they have a tag at the beginning > >>specifying the kind of event. So for instance, when a shared library > >>gets loaded, we get: > >> > >>=shlibs-added,shlib-info= > >>[num="6",name="PBGDBIntrospectionSupport.A.dylib",kind="-",dyld- > >>addr="0x83d50000",reason="dyld",requested- > >>state="?",state="N",path="",description="/Developer/Applications/ > >>Xcode.app/Contents/PlugIns/GDBMIDebugging.xcplugin/Contents/Resources/ > >>PBGDBIntrospectionSupport.A.dylib",slide="",addr="",prefix=""] > > > >OK, so this is exactly what I'm talking about. There needs to be a > >label > >for asynchronous commands. I guess it's not necessary for synchronous > >commands but I think it could be useful to have there anyways and it > >would be trivial to add. > > > >>Again, the truely unsolicited stuff (in this case the breakpoint > >>creation notification) is all tagged so the UI can figure out what is > >>going on. > > > >I think this also needs to be done in the mainline GDB and I would > >prefer the synchronous commands to get a tag also. Do you agree with > >the > >asynchronous part at least? > > > >>> 2. How do you deal with your MI front end dealing with snapshots of > >>> GDB? For example, it has new asynchronous commands, but the MI > >>>version > >>> hasn't been bumped yet. > >> > >>There are two kinds of additions, right? Command return fields, and > >>async notifications. In Xcode, > >>the parser parses everything, and then any command return fields or > >>async notifications that it doesn't understand, it ignores. That's > >>pretty much how the MI was designed, so that the MI can freely ADD > >>notifications & command return fields, and the UI can just ignore > >>them. > >> The fields are identified by field name, and the notifications by > >>their notification name. > > > >OK, so understood. > > > >Commands that add a field will definatly work because the front end > >ignores them. Commands that loose a field will probably cause a major > >problem and will be incompatible with the front end. > > > >What about when a command changes completly because of a version bump? > >What about when the commands changes (like N:M breakpoints) and the > >version is not bumped yet because you have a snapshot of GDB? > > > >I need these case's to work because I am not bundled with GDB. > > > >So again, I'm asking everyone, > > > >1. Can the mainline version get tagged asyncronous commands at the > >least? > >I would prefer every command to have a tag. > > > >2. Can there be a discussion about backwards compatibility with MI > >output commands. This involves several issues I can think of. > > 1. removing fields from an MI output command > > 2. changing the output of an MI output command > > 3. Making the commands themselves be backwards compatible even > > between major releases. This essentially makes the MI output version > > useless. > > > >Thanks, > >Bob Rossi > > > -- > Jim Ingham jingham@apple.com > Developer Tools > Apple Computer