From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3091 invoked by alias); 17 Nov 2012 19:01:24 -0000 Received: (qmail 3025 invoked by uid 48); 17 Nov 2012 19:01:23 -0000 From: "poenitz at htwm dot de" To: gdb-prs@sourceware.org Subject: [Bug mi/14854] New: MI varobj update is not suitable for pyhton pretty printing Date: Sat, 17 Nov 2012 19:01:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: mi X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: poenitz at htwm dot de X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-prs-owner@sourceware.org X-SW-Source: 2012-q4/txt/msg00263.txt.bz2 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.