From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25153 invoked by alias); 14 Sep 2011 08:50:22 -0000 Received: (qmail 24960 invoked by uid 22791); 14 Sep 2011 08:50:19 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp.nokia.com (HELO mgw-sa01.nokia.com) (147.243.1.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 14 Sep 2011 08:50:05 +0000 Received: from gar.localnet (bettdhcp167194.europe.nokia.com [172.25.167.194]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8E8noA4008951; Wed, 14 Sep 2011 11:49:50 +0300 From: =?iso-8859-1?q?Andr=E9_P=F6nitz?= To: gdb-patches@sourceware.org Subject: Re: [MI RFC] entryval: MI access to entry values Date: Wed, 14 Sep 2011 09:13:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.35-30-generic; KDE/4.5.5; i686; ; ) Cc: ext Vladimir Prus , Jan Kratochvil References: <20110718201852.GG30496@host1.jankratochvil.net> <20110913195423.GB16602@host1.jankratochvil.net> <201109141117.42848.vladimir@codesourcery.com> In-Reply-To: <201109141117.42848.vladimir@codesourcery.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201109141049.51904.andre.poenitz@nokia.com> X-Nokia-AV: Clean 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/msg00245.txt.bz2 On Wednesday 14 September 2011 09:17:42 ext Vladimir Prus wrote: > On Tuesday, September 13, 2011 23:54:23 Jan Kratochvil wrote: > > On Fri, 02 Sep 2011 19:07:45 +0200, Jan Kratochvil wrote: > > > (1) > > > so I am inclined to just produce these MI records (which normal and > > > @entry variable variants get included depends on `-gdb-set print > > > entry-values' like in CLI): > > >=20 > > > print_frame_args: > > > *stopped,[...],args=3D[{name=3D"lost",value=3D" > > out>"},{name=3D"lost@entry",value=3D"5"},{name=3D"born",value=3D"10"= }],[...] > > >=20 > > > list_args_or_locals: > > > -stack-list-variables --all-values > > > ^done,variables=3D[{name=3D"lost",arg=3D"1",value=3D" > > out>"},{name=3D"lost@entry",arg=3D"1",value=3D"5"},{name=3D"born",ar= g=3D"1",value > > > =3D"10"}] > >=20 > > FYI chosen this variant in: > > [patch 07/12+doc] entryval#2: Display @entry parameters > > http://sourceware.org/ml/gdb-patches/2011-09/msg00229.html >=20 > Sorry for not responding earlier. This approach certianly looks best for = existing frontneds. In that generality I am afraid I disagree. MI has the ability to transfer d= ata in a structured way, there's no reason to pass the "@entry" marker in-chann= el 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=20 fancy name. This is certainly an acceptable way to do it, but why should that needlessly be steered by gdb? =46rom my point of view, something like=20 ^done,variables=3D[{name=3D"lost",arg=3D"1",value=3D"", atentry=3D"5"},{name=3D"born",arg=3D"1",value=3D"10"}] would be more in the "spirit" of MI, leaving the question of whether this should be presented as one entry, as two, with mangled names or without, with some attempt at localizing the "entry" string or without to the fronte= nd. 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 ef= fort. Andre'