From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22054 invoked by alias); 26 Aug 2004 20:44:45 -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 22010 invoked from network); 26 Aug 2004 20:44:41 -0000 Received: from unknown (HELO maynard.mail.mindspring.net) (207.69.200.243) by sourceware.org with SMTP; 26 Aug 2004 20:44:41 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by maynard.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1C0R6N-00022H-00; Thu, 26 Aug 2004 16:44:07 -0400 Received: from mindspring.com (localhost [127.0.0.1]) by berman.michael-chastain.com (Postfix) with SMTP id BBA7E4B102; Thu, 26 Aug 2004 16:44:07 -0400 (EDT) Date: Thu, 26 Aug 2004 20:44:00 -0000 From: Michael Chastain To: bob@brasko.net Subject: Re: GDB/MI Output Syntax Cc: gdb@sources.redhat.com Message-ID: <412E4B96.nailMU21D4LDE@mindspring.com> References: <20040825154348.GA19533@white> <412CB6B6.nail1DX11BPYQ@mindspring.com> <20040825193659.GA19945@white> <412DED43.nail3XH31S08T@mindspring.com> <20040826183134.GA20902@white> In-Reply-To: <20040826183134.GA20902@white> User-Agent: nail 10.8 6/28/04 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-08/txt/msg00396.txt.bz2 Bob Rossi wrote: > Hmmm, this are some ideas, what do you think? > 1. Run gdb through tee and pipe only GDB's stdout to a place where we > can validate it's output. > 2. Have GDB output it's stdout to 2 places somehow, similar to the > idea above (except maybe a new GDB logging feature), so that the output > can be parsed. > 3. Create a new process, that invokes GDB, validates the output, and > output's exactly what GDB used to output. > 4. Somehow parse the output of GDB, through tcl like you are > suggesting? I think we won't get to a solution today. It's really a problem at the dejagnu/testsuite level. We've got this output stream, but it's mixed in with "PASS: foo" and "Executing on host: bar" in gdb.log. At the test suite level, the TCL code is holding the output and could do something with it. But it's nontrivial for TCL code to interface with a C library. (I'm not about to rebuild the 'expect' binary). Also this might relate to "separating gdb output from inferior output". bob> I don't use this rule in the grammar. I have the lexer return NEWLINE. That's okay, too. Either way is fine with me. I'd like your grammar and the reference grammar to be identical, so that we know that the reference grammar actually works. Grammar comments: === Can you write the terminal symbols in ALL CAPS; that's the usual style for bison grammars. I think the terminals are: STRING C_STRING CR LF TOKEN "(gdb)" "^" "*" "+" "=" "," "~" "@" "&" "done" "running" "connected" "error" "exit" "stopped" The literal strings are okay as is, but I'd really like symbolic terminals capitalized. === Hmmm, in my gdb.log, there is a space in "(gdb) ^M", but in the gdb.texinfo grammar and the new grammar, there is no space. === In the result_record rules: result_record -> opt_token "^" result_class result_record -> opt_token "^" result_class "," opt_result_list In the second form, if there is a ",", there must be at least one result. So the last symbol should be result_list rather than opt_result_list. === Same deal with the async_output rule: async_output -> async_class "," opt_result_list This should be like result_record. If opt_result_list is empty then there is no "," . Example: 403*stopped^M (gdb) ^M In fact async_output doesn't add much value to the grammar. How about just: async_record -> opt_token async_record_class async_class async_record -> opt_token async_record_class async_class "," result_list