From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31808 invoked by alias); 14 Sep 2011 09:13:02 -0000 Received: (qmail 31776 invoked by uid 22791); 14 Sep 2011 09:13:01 -0000 X-SWARE-Spam-Status: No, hits=-6.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 14 Sep 2011 09:12:41 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p8E9Cc6v010452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Sep 2011 05:12:38 -0400 Received: from host1.jankratochvil.net (ovpn-116-38.ams2.redhat.com [10.36.116.38]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p8E9CaCP029111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Sep 2011 05:12:37 -0400 Received: from host1.jankratochvil.net (localhost [127.0.0.1]) by host1.jankratochvil.net (8.14.4/8.14.4) with ESMTP id p8E9CZoF025239; Wed, 14 Sep 2011 11:12:35 +0200 Received: (from jkratoch@localhost) by host1.jankratochvil.net (8.14.4/8.14.4/Submit) id p8E9CY2h025238; Wed, 14 Sep 2011 11:12:34 +0200 Date: Wed, 14 Sep 2011 09:20:00 -0000 From: Jan Kratochvil To: =?utf-8?B?QW5kcsOpIFDDtm5pdHo=?= Cc: gdb-patches@sourceware.org, ext Vladimir Prus Subject: Re: [MI RFC] entryval: MI access to entry values Message-ID: <20110914091233.GA1328@host1.jankratochvil.net> References: <20110718201852.GG30496@host1.jankratochvil.net> <20110913195423.GB16602@host1.jankratochvil.net> <201109141117.42848.vladimir@codesourcery.com> <201109141049.51904.andre.poenitz@nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <201109141049.51904.andre.poenitz@nokia.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-09/txt/msg00246.txt.bz2 On Wed, 14 Sep 2011 10:49:51 +0200, André Pönitz wrote: > In that generality I am afraid I disagree. MI has the ability to transfer data > in a structured way, there's no reason to pass the "@entry" marker in-channel > in the "name" field, and there's no reason to assume that a frontend would > want to present the entry value to the user as a "normal" value, just with a > fancy name. > > This is certainly an acceptable way to do it, but why should that needlessly > be steered by gdb? > > From my point of view, something like > > ^done,variables=[{name="lost",arg="1",value="", > atentry="5"},{name="born",arg="1",value="10"}] "atentry" looks exactly like my "entry_value" proposed as variant (2) in (and implemented in a local patch branch): [MI RFC] entryval: MI access to entry values http://sourceware.org/ml/gdb-patches/2011-09/msg00036.html > would be more in the "spirit" of MI, The problem is the "spirit" of MI is not there. There should be already instead of: {name="lost",arg="1",value=""} rather: {name="lost",arg="1",optimized_out="1"} and for value retrieval error messages ../gdb -nx -i=mi gdb.dwarf2/dw2-param-error -break-insert f -exec-run *stopped,reason="breakpoint-hit",disp="keep",bkptno="1",frame={addr="0x00000000004004b8",func="f",args=[{name="bad",value=""},{name="good",value="23"}]},thread-id="1",stopped-threads="all",core="4" instead of (the current FSF GDB state): {name="bad",value=""} there should be rather: {name="bad",error=""} (this reproducing testcase is by me but this MI behavior existed there a long time before) So exactly in this spirit I chose rather more the front ends simplicity than hypothetical MI protocol ideals. But sure I would rather follow the design goals of the MI maintainer. > Having said that, the proposed output would work, too, and as long as the > mangling is deterministic, a frontend can certainly undo it without much effort. There is already the @entry suffix used in input expressions so it cannot be non-deterministic anyway. At least for C/C++ @entry is not ambigous, neither for Fortran, not sure about all the other languages. Thanks, Jan