From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 129167 invoked by alias); 27 Feb 2015 04:21:05 -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 129151 invoked by uid 89); 27 Feb 2015 04:21:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,KAM_FROM_URIBL_PCCC,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-qc0-f182.google.com Received: from mail-qc0-f182.google.com (HELO mail-qc0-f182.google.com) (209.85.216.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 27 Feb 2015 04:21:03 +0000 Received: by qcvp6 with SMTP id p6so12173176qcv.12 for ; Thu, 26 Feb 2015 20:21:01 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.140.165.198 with SMTP id l189mr25488928qhl.93.1425010861064; Thu, 26 Feb 2015 20:21:01 -0800 (PST) Received: by 10.229.40.69 with HTTP; Thu, 26 Feb 2015 20:21:01 -0800 (PST) In-Reply-To: <87bnkgoki0.fsf@igalia.com> References: <87bnkgoki0.fsf@igalia.com> Date: Fri, 27 Feb 2015 04:21:00 -0000 Message-ID: Subject: Re: Relationship between GDB commands in Python and Guile From: Doug Evans To: Andy Wingo Cc: "gdb-patches@sourceware.org" Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-02/txt/msg00799.txt.bz2 On Thu, Feb 26, 2015 at 5:44 AM, Andy Wingo wrote: > 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 Hi. I've got an opinion on the subject, but I'd like to give the rest of the community a chance to respond first. Cheers.