Re: Relationship between GDB commands in Python and Guile

[Doug Evans <xdje42@gmail.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.