From: Vladimir Prus <vladimir@codesourcery.com>
To: "André Pönitz" <andre.poenitz@mathematik.tu-chemnitz.de>
Cc: Tom Tromey <tromey@redhat.com>, xgsa <xgsa@yandex.ua>,
"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
<Vladimir_Prus@mentor.com>
Subject: Re: [patch] Use the string returned by pretty printer for MI varobjs instead of "{...}"
Date: Thu, 17 May 2012 12:58:00 -0000 [thread overview]
Message-ID: <4FB4F5C8.3060701@codesourcery.com> (raw)
In-Reply-To: <20120517121923.GB6350@klara.mpi.htwm.de>
On 17/05/12 16:19, André Pönitz wrote:
> On Wed, May 16, 2012 at 08:58:42AM -0600, Tom Tromey wrote:
>>>>>>> <andre.poenitz@mathematik.tu-chemnitz.de> writes:
>>
>> Tom> My recollection is that the code originally worked this way, but
>> Tom> Vladimir asked for the "{...}" behavior specifically.
>>
>> André> It might affect frontends taking a "{...}" as indication that
>> André> there are childrens. In fact, I just found some code using that
>> André> as a shortcut.
>>
>> That code is just plain broken, though. The has_more field conveys
>> this information.
>
> If you say so.
>
> 'git blame' thinks you added it in September 2009, so gdb 7.0 is
> probably the first one that has it. Calling code "broken" just
> because it handles (also...) "legacy" setups is a bit of a stretch
> in my opinion.
>
> In any case, I was merely trying to convey the idea that an
> unsuspecting frontend implementor might read the documentation
> in a way that would be incompatible with the change.
>
> I am personally not affected by any change in the -var-*
> output, so maybe I should not have bothered to comment at all.
>
> If you really want to read more into the comment than what was
> actually written, then perhaps a friendly nudge to adapt the
> documentation to existing practice.
I has been quite a while, but I think I was primarily concerned that GDB would abuse value string on varobj
to show what GDB thinks is the right rendering of data. E.g. while "[5]" as top-level value might be a reasonable
rendition for an array with 5 children, it's not entirely clear why GDB's machine interface should take liberties
at telling frontend how to render that. Neither "[", nor 5, nor "]" is integral part of data, and as soon as
GDB outputs that, frontend has no way of knowing whether this is GDB trying to be helpful, or really interesting
data that cannot be obtained in any other way.
--
Vladimir Prus
CodeSourcery / Mentor Graphics
http://www.mentor.com/embedded-software/
next prev parent reply other threads:[~2012-05-17 12:58 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-22 20:17 xgsa
2012-04-27 18:51 ` xgsa
2012-05-03 6:51 ` xgsa
2012-05-03 14:57 ` Joel Brobecker
2012-05-08 6:40 ` xgsa
2012-05-15 5:45 ` xgsa
2012-05-04 7:45 ` Eli Zaretskii
2012-05-15 16:28 ` Tom Tromey
2012-05-16 1:05 ` André Pönitz
2012-05-16 14:59 ` Tom Tromey
2012-05-17 12:19 ` André Pönitz
2012-05-17 12:58 ` Vladimir Prus [this message]
2012-05-17 19:07 ` xgsa
2012-05-21 19:04 ` xgsa
2012-05-17 15:27 ` 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=4FB4F5C8.3060701@codesourcery.com \
--to=vladimir@codesourcery.com \
--cc=Vladimir_Prus@mentor.com \
--cc=andre.poenitz@mathematik.tu-chemnitz.de \
--cc=gdb-patches@sourceware.org \
--cc=tromey@redhat.com \
--cc=xgsa@yandex.ua \
/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