This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug mi/14854] New: MI varobj update is not suitable for pyhtonpretty printing
- From: "poenitz at htwm dot de" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Sat, 17 Nov 2012 19:01:22 +0000
- Subject: [Bug mi/14854] New: MI varobj update is not suitable for pyhtonpretty printing
- Auto-submitted: auto-generated
http://sourceware.org/bugzilla/show_bug.cgi?id=14854
Bug #: 14854
Summary: MI varobj update is not suitable for pyhton pretty
printing
Product: gdb
Version: unknown
Status: NEW
Severity: normal
Priority: P2
Component: mi
AssignedTo: unassigned@sourceware.org
ReportedBy: poenitz@htwm.de
Classification: Unclassified
As discussed on http://sourceware.org/ml/gdb-patches/2012-11/msg00168.html,
MI varobj updates rely on computing differences between previous and current
"state". This cannot work if the pretty printer depends on "external" data,
like global variables or results of function calls unless the MI machinery
would keep track of all such memory accesses and function calls.
This currently does not happen (and is probably not worthwhile or even possible
to implement) rendering MI varobj insuitable for generic use in frontends
outside the area of C struct style displays.
In .gdbinit (or similar):
python
class Printer(object):
def __init__(self, val):
self.val = val
def to_string(self):
return ["foo", "bar"][int(gdb.parse_and_eval("d"))]
def display_hint(self):
return 'string'
def P(val):
if str(val.type) == "struct S":
return Printer(val)
return None
gdb.pretty_printers = [ P ]
end
In main.c:
int d;
struct S { } s;
int main()
{
d = 1;
d = 0;
d = 1;
d = 0;
d = 1;
d = 0;
}
With "full refetch" you get alternating values for s when stepping:
(gdb) display d
1: d = 0
(gdb) display s
2: s = "foo"
(gdb) n
41 d = 0;
2: s = "bar"
1: d = 1
(gdb)
42 d = 1;
2: s = "foo"
1: d = 0
(gdb)
43 d = 0;
2: s = "bar"
1: d = 1
(gdb)
44 d = 1;
2: s = "foo"
1: d = 0
(gdb)
45 d = 0;
2: s = "bar"
1: d = 1
(gdb)
Using MI varobj's you can get something like that:
(gdb) -var-create d * d
^done,name="d",numchild="0",value="0",type="int",has_more="0"
(gdb) -var-create s * s
^done,name="s",numchild="0",value="{...}",type="struct S",has_more="0"
(gdb) n
^running
*running,thread-id="all"
(gdb)
~"39\t d = 0;\n"
*stopped,frame={addr="0x080483e9",...,line="39"},....
(gdb) -var-update *
^done,changelist=[{name="d",in_scope="true",type_changed="false",has_more="0"}]
(gdb) n
^running
*running,thread-id="all"
(gdb)
~"40\t d = 1;\n"
*stopped,frame={addr="0x080483e9",...,line="40"},....
(gdb) -var-update *
^done,changelist=[{name="d",in_scope="true",type_changed="false",has_more="0"}]
Only the changes to d are announced. For the frontend there is no
indication whatsoever that the display of s would need to be updated.
The only way to get the proper alternating display is to fully refetch
everything again:
(gdb) p s
&"p s\n"
~"$1 = \"foo\"\n"
^done
(gdb) p d
&"p d\n"
~"$2 = 0"
~"\n"
^done
(gdb) n
&"n\n"
^running
*running,thread-id="all"
(gdb)
~"41\t d = 0;\n"
*stopped,frame={addr="0x080483fd",...,line="41"},....
(gdb)
p s
&"p s\n"
~"$3 = \"bar\"\n"
^done
(gdb)
Not using varobj and using "full retrieval of all data" solves the problem, and
works well in practice.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.