From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6021 invoked by alias); 15 Jan 2010 09:39:27 -0000 Received: (qmail 5994 invoked by uid 22791); 15 Jan 2010 09:39:26 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 15 Jan 2010 09:39:21 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 178572BABDC for ; Fri, 15 Jan 2010 04:39:20 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nVUdQAnT0f6j for ; Fri, 15 Jan 2010 04:39:20 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 3DC862BABBB for ; Fri, 15 Jan 2010 04:39:19 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 450FAF5970; Fri, 15 Jan 2010 13:39:10 +0400 (RET) Date: Fri, 15 Jan 2010 09:39:00 -0000 From: Joel Brobecker To: gdb-patches@sourceware.org Subject: [RFC] future gdb-gdb.py things in my pipeline... Message-ID: <20100115093910.GD6667@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-01/txt/msg00404.txt.bz2 Hello, Just wanted to throw out some ideas based on my currently limited amount of experience writing a pretty-printer, and maybe discuss some of them if there is interest... * Tom's suggestion for structs: Return a container rather than doing the formatting entirely in the pretty-printer. * My first reaction, after having written the code, is that a lot of fields are handled the same; We just print their value. I think Daniel mentioned that as well. There should be a way for us to have this happen automatically, so that the pretty printer specific to a given type only handles the fields that need special processing (flags, for instance). I'll try to think of something generic that allows us: - exclude certain fields - print the fields we want in the order we want - add certain artificial fields? - other requirements??? * struct type pretty-printer. Would it make sense to print the type code and name even if this information is in main_type. The amount of output generated is still going to be reasonable, while the extra data could be potentially very useful. That should address on of Daniel's comments, BTW. * Should we continue printing the contents of the "fields" array? For large TYPE_CODE_STRUCT types, this can generate a lot of output. I was thinking maybe just print the field's address, and let the user print each field individually. But this pretty printing is partly useful because getting to the fields is a bit of a pain: (gdb) print type.main_type.fld_bdns.fields[0] Right now, the fields are printed like this: field[1]: {name = 0x7f34d0c4c9aa "C6b", type = 0x16fd490, loc_kind = FIELD_LOC_KIND_BITPOS, bitsize = 0, bitpos = 128}, Perhaps we could print that information in a more compact way. field[1]: {name = 0x7f34d0c4c9aa "C6b", type = 0x16fd490, loc_kind = FIELD_LOC_KIND_BITPOS, bitsize = 0, bitpos = 128} We could perhaps even get rid of "loc_kind", which is only useful to know which field to look at in the field_location union. Since the pretty-printer only prints the relevant field, it's a bit redundant. So, we could have: field[1] (bisize = 0, bitpos = 128): {name = 0x7f34d0c4c9aa "C6b", type = 0x16fd490} * We need pretty-printers for other GDB types as well. For instance, a pretty-printer for struct value would be nice... Another for struct cplus_specific would also be useful, I think. Voila voila... -- Joel