From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29275 invoked by alias); 7 Oct 2011 15:16:02 -0000 Received: (qmail 29262 invoked by uid 22791); 7 Oct 2011 15:16:01 -0000 X-SWARE-Spam-Status: No, hits=-7.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 07 Oct 2011 15:15:37 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p97FFbmd025212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 7 Oct 2011 11:15:37 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p97FFaEA014206; Fri, 7 Oct 2011 11:15:36 -0400 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p97FFZr7012510; Fri, 7 Oct 2011 11:15:35 -0400 From: Tom Tromey To: GDB Development Subject: Python and structured output from breakpoint_ops Date: Fri, 07 Oct 2011 15:16:00 -0000 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2011-10/txt/msg00039.txt.bz2 --=-=-= Content-Type: text/plain Content-length: 213 Phil and I have been discussing exposing the print_* breakpoint_ops methods to Python, and we thought we'd take the discussion public. Here is his latest, which quotes my latest; I'll send a reply to this note. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Content-length: 6273 X-From-Line: tromey Wed Oct 5 06:03:34 2011 Return-Path: pmuldoon@redhat.com Received: from localhost [::1] by localhost with IMAP (fetchmail-6.3.20) for (single-drop); Wed, 05 Oct 2011 06:03:34 -0600 (MDT) Received: from zmta02.collab.prod.int.phx2.redhat.com (LHLO zmta02.collab.prod.int.phx2.redhat.com) (10.5.5.32) by mail05.corp.redhat.com with LMTP; Wed, 5 Oct 2011 08:03:08 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zmta02.collab.prod.int.phx2.redhat.com (Postfix) with ESMTP id 20396128010 for ; Wed, 5 Oct 2011 08:03:08 -0400 (EDT) Received: from zmta02.collab.prod.int.phx2.redhat.com ([127.0.0.1]) by localhost (zmta02.collab.prod.int.phx2.redhat.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7SiRr788qDb for ; Wed, 5 Oct 2011 08:03:08 -0400 (EDT) Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by zmta02.collab.prod.int.phx2.redhat.com (Postfix) with ESMTP id 0C13112800E for ; Wed, 5 Oct 2011 08:03:08 -0400 (EDT) Received: from localhost.localdomain (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p95C367H002468 for ; Wed, 5 Oct 2011 08:03:07 -0400 From: Phil Muldoon To: Tom Tromey Subject: Re: structured output Organization: Red Hat References: X-Operating-System: Fedora GNU/Linux Reply-to: pmuldoon@redhat.com X-URL: http://www.redhat.com Date: Wed, 05 Oct 2011 13:03:06 +0100 In-Reply-To: (Tom Tromey's message of "Tue, 04 Oct 2011 10:22:27 -0600") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 Lines: 101 Xref: barimba mail.cygnus:141318 MIME-Version: 1.0 Content-Type: text/plain Content-length: 4244 Tom Tromey writes: > The basic problem is that a "print" method on a breakpoint can be called > in either an MI or CLI context. Inside gdb, we use ui_out to deal with > this, writing ui_out calls which either print text for the CLI or > structured output for MI. Let me say up-front I do not disagree with the idea of structured data, just that the current APIs limit the information we can display to a point where the return in functionality is minimal. Take the "print_one" operation. This is called when "info breakpoints" is called. To attend to the terminology for the way GDB tries to make the breakpoint operations OO in a C world, the "always-called" function which calls the function-pointer for the breakpoint operation, I will call "the parent". Similarly, the function called via function pointer (our operations) I will call "the child". So in print_one's case, the parent does not call the child function until it has already populated all of the fields before address. So there are only two fields left to fill: "address", and "what". They have to be a long and a string. Example: class MyBreakpoint (gdb.Breakpoint): def print_one (self, address): return (address,"Our Breakpoint") The output from "info breakpoints" from the above example: Num Type Disp Enb Address What 1 breakpoint keep y 0x0000000000400532 Our Breakpoint So you can see "Num, Type, Disp and Enb" have been populated before our child function is called. In Python at the moment we do in fact return an iterable for this function, it just so happens we limit it to a tuple (or None). Given that all one can return in the above context is essential a long and a string, I'm not sure what value we can add by letting the user return anything else? We would have to convert any list within the tuple to a string anyway. I'd prefer users just do this themselves in Python. The same goes for print_stop_action. This tells GDB what to print (via an enum) when the breakpoint stops. Example: class MyBreakpoint (gdb.Breakpoint): def print_stop_action (self): return ("Our Breakpoint, ", gdb.PRINT_SRC_AND_LOC) When GDB stops the inferior at a breakpoint defined by this class, GDB will print: Our Breakpoint, foofunc (argc=1, argv=0xff) somewhere/some-file.c:10 So again we are limited to a string and a constant. I guess we could, if the user passed a list within a list, call ui_out_list there. But to me, you will only ever want this output on one line (in fact, it may be a requirement, I am not to sure). There seems to be more room to maneuver with print_mention, and print_one_detail. They are currently implemented as pure strings. But again, both I believe (and really, I want) to be implemented as a single string. print_mention is called when a breakpoint is created. Is there an example of what kind of structured output we could use here? print_one_detail is an optional detail line below each entry for "info breakpoints". This has to be limited to a single line, to remain constant with "info breakpoints" output. In fact, if you look at the mi command -break-list, it just maps to info break and captures that output. Maybe that conversation is what Jan was talking about when there is an explicit mention that any field change has to be made by Vlad? If we are talking about refactoring breakpoint_ops themselves to allow far broader latitude in what they output (allowing print_one to output to all of the fields for example), or adding new fields, then that is another kettle of fish. What do you think? Cheers Phil > We want to mirror this capability in the Python API. There are a lot of > possible ways to do this. Here's one. > > Instead of a "print" method on a Python breakpoint object, have a > "describe" method that returns an iterable object (e.g., usually a > list). The C code will iterate over all the elements in the sequence. > If a given element is a string, it is passed to ui_out_text. Other > types of elements would then be available and be converted to other > kinds of ui_out calls. I didn't work out all the details, but e.g., a > Python list could be converted to a ui_out_list. > > > Tom --=-=-= Content-Type: text/plain Content-length: 6 Tom --=-=-=--