From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2472 invoked by alias); 28 Mar 2011 06:13:33 -0000 Received: (qmail 2463 invoked by uid 22791); 28 Mar 2011 06:13:32 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp.nokia.com (HELO mgw-da02.nokia.com) (147.243.128.26) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 28 Mar 2011 06:13:25 +0000 Received: from gar.localnet (berwst16747.europe.nokia.com [172.25.167.47]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p2S6DLJj010739; Mon, 28 Mar 2011 09:13:21 +0300 From: =?iso-8859-1?q?Andr=E9_P=F6nitz?= To: gdb@sourceware.org Subject: Re: MI Interface - interpretation of value returned by -stack-list-locals (C++) Date: Mon, 28 Mar 2011 06:13:00 -0000 User-Agent: KMail/1.13.2 (Linux/2.6.32-21-generic; KDE/4.4.5; i686; ; ) Cc: ext BarrRobot References: <31246347.post@talk.nabble.com> In-Reply-To: <31246347.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201103280817.29210.andre.poenitz@nokia.com> X-Nokia-AV: Clean X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2011-03/txt/msg00170.txt.bz2 On Saturday 26 March 2011 17:36:23 ext BarrRobot wrote: > > The value returned by "-stack-list-locals 1" (inter alia) is of the form: > > ^done,locals=[{name="variable",value="a quoted string"}....] > > i.e. a List of Tuples containing Results. > > When "variable" of the first Result is a 'complex' type - typically an > instantiated class, the quoted string Value of the second appears to be > exactly the same (with allowance for escaped characters) as that produced by > the equivalent console interface (CLI) command and whilst parts of it > conform to the MI output specification, other parts - I am thinking of the > representation of arrays - do not. Is there an intention to present the > entire output of these commands in the defined MI output syntax, and if not, > what is the recommended way to handle this part of the output, i.e. is it > the expectation to present it 'as is' to the user, or is it safe to attempt > to parse out the component parts and their values with rules derived from > the CLI output? [I am only a user of MI, so that's not an authoritative answer.] I think the idea is to present the data to your users in a way you (or even they ;-}) see fit. If that requires extra formatting or "enrichment" on top of what is provided by default gdb output it's the task of the MI "consumer" to create this - possibly by additional communication with gdb. There will be always special wishes regarding formatting or display layout, and the gdb side cannot be expected to hardcode all of them. The only scalable solution is providing hooks for user defined functionality, and for that gdb already provides Python based scripting. Andre'