From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11365 invoked by alias); 14 Sep 2011 10:26:24 -0000 Received: (qmail 11346 invoked by uid 22791); 14 Sep 2011 10:26:23 -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 10:25:59 +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 p8EAPuAJ019607 for ; Wed, 14 Sep 2011 13:25:56 +0300 From: =?utf-8?q?Andr=C3=A9_P=C3=B6nitz?= To: gdb-patches@sourceware.org Subject: Re: [MI RFC] entryval: MI access to entry values Date: Wed, 14 Sep 2011 10:45:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.35-30-generic; KDE/4.5.5; i686; ; ) References: <20110718201852.GG30496@host1.jankratochvil.net> <201109141049.51904.andre.poenitz@nokia.com> <20110914091233.GA1328@host1.jankratochvil.net> In-Reply-To: <20110914091233.GA1328@host1.jankratochvil.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201109141225.56344.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/msg00249.txt.bz2 On Wednesday 14 September 2011 11:12:33 ext Jan Kratochvil wrote: > On Wed, 14 Sep 2011 10:49:51 +0200, Andr=C3=A9 P=C3=B6nitz wrote: > > In that generality I am afraid I disagree. MI has the ability to transf= er data > > in a structured way, there's no reason to pass the "@entry" marker in-c= hannel > > in the "name" field, and there's no reason to assume that a frontend wo= uld > > want to present the entry value to the user as a "normal" value, just w= ith a=20 > > fancy name. > >=20 > > This is certainly an acceptable way to do it, but why should that needl= essly > > be steered by gdb? > >=20 > > From my point of view, something like=20 > >=20 > > ^done,variables=3D[{name=3D"lost",arg=3D"1",value=3D"= ", > > atentry=3D"5"},{name=3D"born",arg=3D"1",value=3D"10"}] >=20 > "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 >=20 >=20 > > would be more in the "spirit" of MI, >=20 > The problem is the "spirit" of MI is not there.=20=20 I was assuming it at least partially was, and when there are two possible ways to add new stuff, there could be a bias to the one that's more "in the spirit". > There should be already instead of: > {name=3D"lost",arg=3D"1",value=3D""} > rather: > {name=3D"lost",arg=3D"1",optimized_out=3D"1"} That's actually what I'd prefer, too. No magic in-channel strings that need to be recognized and handled/translated separately, but different kinds of data transferred in different channels. I actually had already a stanza like that in the previous mail but removed it before sending, as I did not want to trigger a compatibilty discussion. > and for value retrieval error messages > ../gdb -nx -i=3Dmi gdb.dwarf2/dw2-param-error > -break-insert f > -exec-run > *stopped,reason=3D"breakpoint-hit",disp=3D"keep",bkptno=3D"1", > time before) >=20 > So exactly in this spirit I chose rather more the front ends simplicity t= han > hypothetical MI protocol ideals. After giving some more thought I guess you and Volodya are indeed right. Adding new ad-hoc data mangling is probably really the best for all existin= g=20 frontends. For the "we just dump gdb output into a treeview"-kind of FE usi= ng=20 whatever looks ok on the commandline is fine in the view, and the few other= s=20 have to massage the output anyway. Adding yet another five lines of code to recognize and modify the new entries is certainly less effort for the respe= ctive maintainers than pondering the spiritual dimension of a protocol first. > But sure I would rather follow the design goals of the MI maintainer. Absolutely. Regards, Andre'