Relationship between GDB commands in Python and Guile

[Andy Wingo <wingo@igalia.com>]

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