Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "André Pönitz" <andre.poenitz@nokia.com>
To: gdb-patches@sourceware.org
Cc: ext Vladimir Prus <vladimir@codesourcery.com>,
	       Jan Kratochvil <jan.kratochvil@redhat.com>
Subject: Re: [MI RFC] entryval: MI access to entry values
Date: Wed, 14 Sep 2011 09:13:00 -0000	[thread overview]
Message-ID: <201109141049.51904.andre.poenitz@nokia.com> (raw)
In-Reply-To: <201109141117.42848.vladimir@codesourcery.com>

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):
> > > 
> > > print_frame_args:
> > > 	*stopped,[...],args=[{name="lost",value="<optimized
> > > 	out>"},{name="lost@entry",value="5"},{name="born",value="10"}],[...]
> > > 
> > > list_args_or_locals:
> > > 	-stack-list-variables --all-values
> > > 	^done,variables=[{name="lost",arg="1",value="<optimized
> > > 	out>"},{name="lost@entry",arg="1",value="5"},{name="born",arg="1",value
> > > 	="10"}]
> > 
> > FYI chosen this variant in:
> > 	[patch 07/12+doc] entryval#2: Display @entry parameters
> > 	http://sourceware.org/ml/gdb-patches/2011-09/msg00229.html
> 
> 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 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="<optimized out>",
        atentry="5"},{name="born",arg="1",value="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 frontend.

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.

Andre'


  reply	other threads:[~2011-09-14  8:50 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-18 20:21 [RFC 06/12] entryval: Display @entry parameters in bt full Jan Kratochvil
2011-07-18 22:24 ` Daniel Jacobowitz
2011-07-19 10:48   ` Eli Zaretskii
2011-07-19 10:55     ` Jan Kratochvil
2011-07-19 11:52       ` Eli Zaretskii
2011-07-19 12:17         ` Jakub Jelinek
2011-07-19 16:46           ` Eli Zaretskii
2011-07-19 17:22             ` Jakub Jelinek
2011-08-03 17:27           ` Jan Kratochvil
2011-08-03 17:53             ` Jan Kratochvil
2011-08-03 18:13               ` Jan Kratochvil
2011-08-03 18:36             ` Tom Tromey
2011-08-03 19:43   ` Jan Kratochvil
2011-09-02 17:08   ` [MI RFC] entryval: MI access to entry values [Re: [RFC 06/12] entryval: Display @entry parameters in bt full] Jan Kratochvil
2011-09-13 21:35     ` [MI RFC] entryval: MI access to entry values Jan Kratochvil
2011-09-14  8:50       ` Vladimir Prus
2011-09-14  9:13         ` André Pönitz [this message]
2011-09-14  9:20           ` Jan Kratochvil
2011-09-14 10:45             ` André Pönitz
2011-10-03 17:00               ` Tom Tromey
2011-10-03 16:57     ` [MI RFC] entryval: MI access to entry values [Re: [RFC 06/12] entryval: Display @entry parameters in bt full] Tom Tromey
2011-10-03 17:05       ` Vladimir Prus
2011-10-03 17:44         ` Jan Kratochvil
2011-10-03 18:14           ` Joel Brobecker
2011-10-10 16:09           ` André Pönitz
2011-07-19 10:57 ` [RFC 06/12] entryval: Display @entry parameters in bt full Eli Zaretskii
2011-07-19 16:21 ` Tom Tromey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201109141049.51904.andre.poenitz@nokia.com \
    --to=andre.poenitz@nokia.com \
    --cc=gdb-patches@sourceware.org \
    --cc=jan.kratochvil@redhat.com \
    --cc=vladimir@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox