From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22911 invoked by alias); 21 Sep 2004 18:25:04 -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 22816 invoked from network); 21 Sep 2004 18:25:01 -0000 Received: from unknown (HELO lakermmtao11.cox.net) (68.230.240.28) by sourceware.org with SMTP; 21 Sep 2004 18:25:01 -0000 Received: from white ([68.9.64.121]) by lakermmtao11.cox.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20040921182501.XZFR9160.lakermmtao11.cox.net@white> for ; Tue, 21 Sep 2004 14:25:01 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1C9pK0-0006ZR-00 for ; Tue, 21 Sep 2004 14:25:00 -0400 Date: Tue, 21 Sep 2004 18:25:00 -0000 From: Bob Rossi To: gdb@sources.redhat.com Subject: MI output commands and backwards compatibility Message-ID: <20040921182500.GA25252@white> Mail-Followup-To: gdb@sources.redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-SW-Source: 2004-09/txt/msg00173.txt.bz2 Hi, As you know, I've been working on a parser for the MI output commands. This seems to be going very well, and hopefully, after it has been tested for a while, I've proposed using it to validate the output of the GDB in the testsuite. However, I have run into several other questions now that I have broken up GDB's MI output command into a higher level. For the sake of this Email I will refer to the "higher level" as a "parse tree" or PT. For example, I have basically broken up two possible ways to understand GDB's MI output commands. They are, 1. The front end must know what command it issued, therefore knowing what MI output command was sent back, and then it is capable of walking the parse tree to get the data it needs. 2. The front end has a parse tree, and it must look at the data in the parse tree to figure out what type of MI output command was sent by GDB. After it figures out what type of command it received, it can then move into the case above. The first rule is necessary because two MI output commands could have the exact same syntax, and therefor create the same PT. When a front end goes to walk the PT, it can not figure out just from the PT what the data is referring to, or what to do with the data. Because of this problem it is only possible for the front end to understand what the parse tree represents by knowing what MI output command generated the parse tree. ( I know that using the [token] in the grammar mostly solves this problem ) Also, the second situation is where it gets more confusing. This happens with asynchronous commands are sent from GDB to the front end. Since the front end didn't ask for anything it has no idea what command it just received. Looking at the parse tree is the only way it can figure out what command GDB just sent it. Unfortunately, it is possible that the front end has to look pretty deep into the PT to actually determine what kind of output command was just received. Also, because MI output commands could potentially have the same output, in certain circumstances, it would be impossible to determine the type of MI output command that is being received just by looking at the parse tree. Remember the front end must first know what kind of command it is receiving before it can make any sense out of the command. In short, once you figure out what type of MI output command you just received, if this is possible, you can then move up to case #1 and walk the PT to get the data that you need. I have a solution to this problem, that I think will also satisfy the requirements for backwards compatibility. I originally proposed that every MI output command should be backwards compatible, otherwise, if this can not be done, a new MI output command is created to take the place of the old one. To do this, we can prefix the MI output syntax to have a unique label, representing the type of output command that was just sent. So, the top level grammar could change from output => ( out-of-band-record )* [ result-record ] "(gdb)" nl to output => label ( out-of-band-record )* [ result-record ] "(gdb)" nl label => label "=" cstring With this information, once a front end was programmed to handle a certain MI output command ( label ), it will always be able to handle that MI output command. Also, snapshots of GDB between major releases will also not be a problem. If this would be acceptable, I would happily come up with a patch to make this change. To recap, this solution would solve 2 problems, - The ability for front ends to have backwards compatibility with MI output commands. - The ability of the front end to understand which MI output command it is walking, in order to semantically understand what to do with the data. Finally, this solution only effects the MI output commands. The MI input commands are not addressed here. Thanks, Bob Rossi