This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |