From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32581 invoked by alias); 26 Feb 2015 13:44:30 -0000 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 Received: (qmail 32570 invoked by uid 89); 26 Feb 2015 13:44:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL autolearn=ham version=3.3.2 X-HELO: sasl.smtp.pobox.com Received: from pb-sasl1.int.icgroup.com (HELO sasl.smtp.pobox.com) (208.72.237.25) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 26 Feb 2015 13:44:29 +0000 Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id 40924319D1 for ; Thu, 26 Feb 2015 08:44:27 -0500 (EST) Received: from pb-sasl1.int.icgroup.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id 383FE319CF for ; Thu, 26 Feb 2015 08:44:27 -0500 (EST) Received: from rusty (unknown [88.160.190.192]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pb-sasl1.pobox.com (Postfix) with ESMTPSA id 81E2E319CE for ; Thu, 26 Feb 2015 08:44:26 -0500 (EST) From: Andy Wingo To: gdb-patches@sourceware.org Subject: Relationship between GDB commands in Python and Guile Date: Thu, 26 Feb 2015 13:44:00 -0000 Message-ID: <87bnkgoki0.fsf@igalia.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Pobox-Relay-ID: 948B47BE-BDBD-11E4-B2DD-8FDD009B7A5A-02397024!pb-sasl1.pobox.com X-SW-Source: 2015-02/txt/msg00758.txt.bz2 Hi, "info pretty-printers" won't list pretty-printers that are written in Scheme. Likewise for type printers, frame filters, in the future frame sniffers, etc etc. Is there a story about how this is supposed to work? Options: 1. Do nothing, you have to use a Guile API to query and manipulate Guile pretty-printers. 2. Somehow bake the abstraction of registered pretty printers more deeply into GDB, and move the implementation of the command into GDB core. 3. Somehow bake the abstraction of registered pretty printers more deeply into GDB, but still have the command implemented in Python. 4. Have Python provide a hooks for each of these commands by which Guile could provide it with additional entries. Pretty nasty. Not sure if there are more options. I think (1) is an OK option if that's what the maintainers choose, but I wanted to know. (3) seems to me to be the other viable option. Something like: struct extension { const char *name; bool is_enabled; int priority; enum extension_language language; void *data; }; void free_extension (struct extension *ext) { /* language-specifc free of ext->data, like Py_DecRef */ free (ext); } enum extension_type { EXT_TYPE_PRETTY_PRINTER, EXT_TYPE_FRAME_FILTER, ... }; enum extension_visit_result { /* Stop visiting extensions. */ EXT_VISIT_DONE, /* Keep on visiting extensions. */ EXT_VISIT_CONTINUE, /* Whoa Nellie! */ EXT_VISIT_ERROR }; typedef enum extension_visit_result extension_visitor (struct extension*, void *); void visit_all_extensions (enum extension_type type, extension_visitor visit, void *data); void visit_extensions_for_progspace (enum extension_type type, struct program_space *progspace, extension_visitor visit, void *data); Et cetera. The invocation mechanism for extensions could remain the same. This could just remain a common query API to find and/or collect extensions. An open question would be how to indicate that python extensions win over guile extensions. Perhaps we should query extensions by language, then, and then list python ones first. Having a unified "priority" doesn't make sense in that context. Perhaps the pretty-printing (etc) mechanism should, in that case, instead be more fine-grained -- not just "try python first", but instead trying the printers (frame filters, etc) in order of priority. Perhaps that's too much setup work though; not sure what the cost is to "enter" python mode etc. I'm very pleased about the Guile integration, but I do understand that having two extension languages raises a number of irritating issues like this one and that might lead to choosing option (1) over something more unified. That's fine by me. Let me know your thoughts! Andy