From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11530 invoked by alias); 22 Dec 2007 07:17:27 -0000 Received: (qmail 11518 invoked by uid 22791); 22 Dec 2007 07:17:26 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 22 Dec 2007 07:17:19 +0000 Received: (qmail 24572 invoked from network); 22 Dec 2007 07:17:17 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 22 Dec 2007 07:17:17 -0000 To: "Doug Evans" Cc: gdb@sourceware.org Subject: Re: use of python to pretty-print STL structures, etc. References: From: Jim Blandy Date: Sat, 22 Dec 2007 07:17:00 -0000 In-Reply-To: (Doug Evans's message of "Fri, 21 Dec 2007 13:57:19 -0800") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes 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: 2007-12/txt/msg00164.txt.bz2 "Doug Evans" writes: > I realize there's no real design as of yet (at least that I'm aware > of), but my question is whether folks have thought about what it would > look like from the command line. > > At a very basic level, do folks envision keeping the current cli u/i > (*1) and enhancing it to provide python-providable extensions? Have > folks thought about how they would like the above problem to be solved > (with python or without)? My dream is to let people put a gdb-custom.py file in their source trees, and then have GDB automatically look for that and load it if present. gdb-custom.py would say something like: def print_foo (obj): ... code to print a GDB value whose type is 'foo' nicely ... print_type_with ('foo', print_foo) And then the fundamental GDB printing code would defer to print_foo as needed --- whether the 'foo' appeared as the entire value of the expression, or as a member of a structure or array. So not only 'print' and 'display', but also 'frame', 'finish', and everything else would use print_foo. Since gdb-custom.py would get loaded automatically, it wouldn't take any special effort to get GDB to print a program's values in a meaningful way --- you'd just debug the program normally, and you'd get appropriate representations. People who never wanted custom printing could put 'set python auto-load off' in their ~/.gdbinit files. Some format specifier, say /q, would disable all custom printing things, so you could see what was underneath it. The output from 'print_foo' might be wrapped in some brackets or have a special (brief) prefix to distinguish it from ordinary GDB values. I don't know how you'd register a handler for 'vector' for all T. Or how the printing procedure would obtain the T at hand. Maybe you'd pass an instance of some class to print_type_with, not just a procedure, to register a collection of operations for 'foo' all at once, if there's something we care about beyond printing. A winning solution would have many useful, tempting examples less than 20 lines long, so people could just get the gist of the interface and play with it.