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]

Re: [PATCH] Debug Methods in GDB Python


On Thu, Dec 5, 2013 at 10:30 PM, Doug Evans <xdje42@gmail.com> wrote:
> Sorry for the delay.
> I've been wanting to find time to investigate some of the suggestions I made.
> e.g., instead of DEFAULT_DEBUG_METHOD_GROUP, etc.
> have the grouping work the same way it does for the libstdc++
> pretty-printers.  Have you thought about it?

I have removed DEFAULT_DEBUG_METHOD_GROUP from the code in my latest
patch. However, there is one reference to it in the brief (really
brief!) doc change I have in the patch [1]. About grouping in
libstdc++, is it not doing a grouping within what is facilitated by
the pretty printing API? For debug methods, I have added grouping wrt
obj file, progspace, and global. I have not implemented the notion of
sub debug methods (pretty printing API allows the user to bring in a
notion of sub printers). There are two reason for this. 1. It is a
convenience facility for the user which can be added easily if the
base API is agreed upon. 2. This is a personal reason, which you could
override: In the pretty printers world, each class would typically
have only one pretty printer implementation. For debug methods though,
each class could possibly have multiple debug methods. In which case,
having a notion of sub debug methods is probably more meaningful at
the class level. That is, it is more meaningful to have a "debug
methods of a class" grouping. And, this grouping can be easily
achieved by a debug method naming convention.

[1] I am really scared to write a full doc entry if the base API is
not agreed upon yet.

Thanks,
Siva Chandra


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]