From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16406 invoked by alias); 23 Aug 2004 21:03:27 -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 16391 invoked from network); 23 Aug 2004 21:03:24 -0000 Received: from unknown (HELO lakermmtao08.cox.net) (68.230.240.31) by sourceware.org with SMTP; 23 Aug 2004 21:03:24 -0000 Received: from white ([68.9.64.121]) by lakermmtao08.cox.net (InterMail vM.6.01.03.02.01 201-2131-111-104-103-20040709) with ESMTP id <20040823210321.MMYE28752.lakermmtao08.cox.net@white> for ; Mon, 23 Aug 2004 17:03:21 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1BzLyE-000451-00 for ; Mon, 23 Aug 2004 17:03:14 -0400 Date: Mon, 23 Aug 2004 21:03:00 -0000 From: Bob Rossi To: gdb@sources.redhat.com Subject: GDB/MI Output Syntax ambiguity Message-ID: <20040823210314.GA15374@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-08/txt/msg00297.txt.bz2 Hi, I am generating a bottom up parser for 'GDB/MI Output Syntax' using bison. Unfortunately, I think that I found an ambiguity, which makes it not easily parsable. Please correct me if I am wrong. output -> ( out-of-band-record )* [ result-record ] "(gdb)" nl result-record -> [ token ] "^" result-class ( "," result )* nl out-of-band-record -> async-record | stream-record async-record -> exec-async-output | status-async-output | notify-asyn exec-async-output -> [ token ] "*" async-output status-async-output -> [ token ] "+" async-output notify-async-output -> [ token ] "=" async-output I am assuming that the grammar above for 'output' means that there can be 0 or more 'out-of-band-record', followed by 0 or 1 'result-record', followed by '(gdb)' and then a newline. The problem is, when you are parsing 'output', and you get a 'token' as the first token from the lexer, you don't know if that is part of the 'out-of-band-record' or if it is part of the 'result-record'. Both of these rules optionally start with 'token'.Has anyone actually written a recursive descent parser, or generated a parser from bison for GDB/MI's output yet, or am I the first? Help would be greatly appreciated. This is the only shift/reduce conflict I have in my modified BNF version of the grammar. Other than this, the grammar looks very well written. I consider this to be a serious problem so I hope that I am not doing something incorrectly or am mis-understanding the grammar. Thanks, Bob Rossi