Relationship between GDB commands in Python and Guile

Relationship between GDB commands in Python and Guile

[Andy Wingo]

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

Re: Relationship between GDB commands in Python and Guile

[Doug Evans]

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.

Re: Relationship between GDB commands in Python and Guile

[Pedro Alves]

On 02/27/2015 04:21 AM, Doug Evans wrote:
> 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.

Off hand, my opinion would be that dependencies between extensions languages
are best avoided, and thus it'd seem to me that (2) would be the
sanest option.

Thanks,
Pedro Alves

Re: Relationship between GDB commands in Python and Guile

[Yao Qi]

Andy Wingo <wingo@igalia.com> writes:

> "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.

I don't know much about gdb python/guile extension, but I prefer 2.

> 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'd like to know why is such question raised?  In practise, is it common
that users install two pretty-printers, one is python and one is guile?

IMO, extensions by different languages are fair to each other.

-- 
Yao (齐尧)

Re: Relationship between GDB commands in Python and Guile

[Andy Wingo]

Hi,

Quick answer:

On Tue 17 Mar 2015 13:04, Yao Qi <qiyaoltc@gmail.com> writes:

> Andy Wingo <wingo@igalia.com> writes:
>
>> 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'd like to know why is such question raised?  In practise, is it common
> that users install two pretty-printers, one is python and one is guile?

Imagine a program that uses two libraries, one of which has a
libfoo-gdb.py file installed, and the other that has libbar-gdb.scm
installed.  Then you could have pretty printers, frame filters,
unwinders, etc defined for each library but in different languages.

Andy

Re: Relationship between GDB commands in Python and Guile

[Doug Evans]

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!

From my observations, I'd say (1) is the only viable option, with one
modification:
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
my-guile-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.