Bug 10616 - Pretty-printed MI vars with children get "{...}" instead of the wanted string
Summary: Pretty-printed MI vars with children get "{...}" instead of the wanted string
Status: RESOLVED INVALID
Alias: None
Product: gdb
Classification: Unclassified
Component: mi (show other bugs)
Version: archer
: P2 normal
Target Milestone: 6.8
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-09-08 07:51 UTC by Noam Yorav-Raphael
Modified: 2009-09-08 19:34 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
File needed to recreate the bug (113 bytes, text/x-csrc)
2009-09-08 07:52 UTC, Noam Yorav-Raphael
Details
File needed to recreate the bug (192 bytes, text/x-python)
2009-09-08 07:52 UTC, Noam Yorav-Raphael
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Noam Yorav-Raphael 2009-09-08 07:51:59 UTC
Hello,

If a pretty-printed variable has children, in MI the to_string method is
ignored, and istead "{...}" is used.

To recreate:
Download bug.c, bug.py (They are the same as in bug 10615).
> gdb --int mi2 --nx bug
> -enable-pretty-printing
> python execfile('bug.py')
> b main
> r
> n
> -var-create m * m
^done,name="m",numchild="0",value="{...}",type="MainStruct",thread-id="1",has_more="1"

The value should have been "x=0".

To fix this, remove those two lines from varobj.c:

    if (dynamic_varobj_has_child_method (var))
  	  return xstrdup ("{...}");

They suggest that this behaviour was intentional. However, I would prefer if it
weren't so. I wrote a pretty-printer for a struct. The struct has many fields,
but only two are important. So I wrote a pretty-printer which keeps the children
of the struct, but uses to_string to display a string like "x=3,y=5", which
helps me see the important state of the struct in the GUI debugger without
having to open the struct in the tree view, so I have more space for watching
other variables.

Thanks,
Noam
Comment 1 Noam Yorav-Raphael 2009-09-08 07:52:19 UTC
Created attachment 4180 [details]
File needed to recreate the bug
Comment 2 Noam Yorav-Raphael 2009-09-08 07:52:32 UTC
Created attachment 4181 [details]
File needed to recreate the bug
Comment 3 Noam Yorav-Raphael 2009-09-08 07:53:37 UTC
I forgot: of course, you have to compile before anything:
> gcc -g -o bug bug.c
Comment 4 Tom Tromey 2009-09-08 19:34:06 UTC
Yeah, this behavior in intentional.
I think you should raise this issue on the mailing list, there
are a couple threads touching on this.
bugzilla isn't really the best place to discuss it, as not everybody
is listening here.  I'm closing the bug for this reason.