Re: [RFC] Debug Methods in GDB Python

[Siva Chandra <sivachandra at google dot com>]

Hi,

I apologize for this long hiatus. I now have a new patch in response
to Tom's last round of review. I am not very clear with some of his
comments and have few questions in response.  Also, Tom asked for docs
with his last review. I have added a section to the doc which
illustrates the debug method API/usage, but is in no way complete yet.

2013-11-11  Siva Chandra Reddy  <sivachandra@google.com>

        Add Debug methods support in GDB.

        * Makefile.in: Add entries for new files
        * data-directory/Makefile.in: Add entry for new Python file
        * eval.c: Invoke methods defined in extension methods.
        * ext-function.c: Support for working with functions/methods
        defined in an extension language.
        * ext-function.h: Support for working with functions/methods
        defined in an extension language.
        * python/lib/gdb/debugmethods.py: Python side of the support
        for debug methods in Python.
        * python/py-debugmethods.c: C side of the support for debug
        methods in Python.
        * python/py-objfile.c: Add 'debug_methods' attribute to
        gdb.Objfile.
        * python/python-internal.h: Add new function
        gdb.enable_debug_methods to the Python module 'gdb'.
        * python/python.c: Add new function gdb.enable_debug_methods to
        the Python module 'gdb'.
        * python/python.h: Add declarations of new functions.
        * valarith.c: Invoke operators defined in extension languages.
        * valops.c: Lookup methods defined in extension languages.
        * value.h: New signature for 'find_overload_match'.

On Mon, Jul 22, 2013 at 1:47 PM, Tom Tromey <tromey@redhat.com> wrote:
> The "extension language" code here seems like a lot of work for no
> real benefit.
>
> It's fine for the functions themselves, since we'd like to keep the API
> to the Python layer reasonably thin.  But for get_matching_ext_methods,
> e.g., it is simple to follow the existing pattern: declare a function in
> python.h and provide both with- and without-Python implementations.

I am not sure I understand what is being said here. Could you kindly
elaborate (pointing to an existing example)?

> Silently ignoring errors doesn't seem right.
> There are a few instances of this.
>
> I'm not really sure about the error-handling strategy in this function.

They way I have looked at debug methods hook is as follows:
"If there exists a Python implementation or replacement which matches
better or is as good a match as the source implementation, then use
the Python implementation. If there is any error looking up Python
implementations, report the error but do not stop from executing an
operation; proceed to use the source implementation."

With that view, in the latest patch, I have modified to print the
errors instead of silently ignoring them. Let me know if this does not
seem to be a good strategy.

> I'm curious if you ran this through the checker.

I have not run it through the checker.

Attachment: dm_patch_v5.txt
Description: Text document