Re: Relationship between GDB commands in Python and Guile

[Pedro Alves <palves at redhat dot com>]

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