public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug mi/14854] New: MI varobj update is not suitable for pyhton pretty printing
@ 2012-11-17 19:01 poenitz at htwm dot de
2013-01-03 22:19 ` [Bug mi/14854] MI varobj update is not suitable for python " poenitz at htwm dot de
2023-08-31 17:30 ` [Bug varobj/14854] " tromey at sourceware dot org
0 siblings, 2 replies; 3+ messages in thread
From: poenitz at htwm dot de @ 2012-11-17 19:01 UTC (permalink / raw)
To: gdb-prs
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug mi/14854] MI varobj update is not suitable for python pretty printing
2012-11-17 19:01 [Bug mi/14854] New: MI varobj update is not suitable for pyhton pretty printing poenitz at htwm dot de
@ 2013-01-03 22:19 ` poenitz at htwm dot de
2023-08-31 17:30 ` [Bug varobj/14854] " tromey at sourceware dot org
1 sibling, 0 replies; 3+ messages in thread
From: poenitz at htwm dot de @ 2013-01-03 22:19 UTC (permalink / raw)
To: gdb-prs
http://sourceware.org/bugzilla/show_bug.cgi?id=14854
Andre' Poenitz <poenitz at htwm dot de> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |http://sourceware.org/bugzi
| |lla/show_bug.cgi?id=12806
Summary|MI varobj update is not |MI varobj update is not
|suitable for pyhton pretty |suitable for python pretty
|printing |printing
--
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug varobj/14854] MI varobj update is not suitable for python pretty printing
2012-11-17 19:01 [Bug mi/14854] New: MI varobj update is not suitable for pyhton pretty printing poenitz at htwm dot de
2013-01-03 22:19 ` [Bug mi/14854] MI varobj update is not suitable for python " poenitz at htwm dot de
@ 2023-08-31 17:30 ` tromey at sourceware dot org
1 sibling, 0 replies; 3+ messages in thread
From: tromey at sourceware dot org @ 2023-08-31 17:30 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=14854
Tom Tromey <tromey at sourceware dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|mi |varobj
CC| |tromey at sourceware dot org
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2023-08-31 17:30 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-11-17 19:01 [Bug mi/14854] New: MI varobj update is not suitable for pyhton pretty printing poenitz at htwm dot de
2013-01-03 22:19 ` [Bug mi/14854] MI varobj update is not suitable for python " poenitz at htwm dot de
2023-08-31 17:30 ` [Bug varobj/14854] " tromey at sourceware dot org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).