[Bug mi/14854] New: MI varobj update is not suitable for pyhton pretty printing

["poenitz at htwm dot de" <sourceware-bugzilla@sourceware.org>]

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.