This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Relationship between GDB commands in Python and Guile
- From: Doug Evans <xdje42 at gmail dot com>
- To: Andy Wingo <wingo at igalia dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Thu, 26 Feb 2015 20:21:01 -0800
- Subject: Re: Relationship between GDB commands in Python and Guile
- Authentication-results: sourceware.org; auth=none
- References: <87bnkgoki0 dot fsf at igalia dot com>
On Thu, Feb 26, 2015 at 5:44 AM, Andy Wingo <wingo@igalia.com> 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.