This is the mail archive of the
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: Tue, 17 Mar 2015 08:50:03 -0700
- 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 <firstname.lastname@example.org> wrote:
> "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?
> 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;
> free_extension (struct extension *ext)
> /* language-specifc free of ext->data, like Py_DecRef */
> free (ext);
> enum extension_type
> enum extension_visit_result
> /* Stop visiting extensions. */
> /* Keep on visiting extensions. */
> /* Whoa Nellie! */
> 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
> 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!
>From my observations, I'd say (1) is the only viable option, with one
In the beginning there was opposition to imposing anything on the python side,
and while (2) was always on my mind from the beginning, at the time it wasn't
going to fly. So I figured ok, if I can't have "disable pretty-printer
I can still have either "disable guile pretty-printer my-guile-printer"
or "guile disable pretty-printer my-guile-printer"
(and so on for "info pretty-printer", etc.).
The latter choice might have had to use a different prefix than
"guile" of course.
So while there aren't such commands today, they weren't precluded.
It's not an ideal choice, but at least it was something
(given that the only alternative at the time was to have no CLI
interface at all).
Having said that, I can go with something that allows for
"info pretty-printer", etc. to work with Guile extensions,
but one would need to weigh the cost/benefits of it.