This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Debug Methods in GDB Python
- From: Siva Chandra <sivachandra at google dot com>
- To: Doug Evans <xdje42 at gmail dot com>
- Cc: gdb-patches <gdb-patches at sourceware dot org>
- Date: Fri, 6 Dec 2013 15:24:34 -0800
- Subject: Re: [PATCH] Debug Methods in GDB Python
- Authentication-results: sourceware.org; auth=none
- References: <CAGyQ6gxURLZn0bVH0ztDsyqNyNCNsEx-QkJa6OLd0o8u4Vv_Yg at mail dot gmail dot com> <CAGyQ6gxe2UiMFJs6LDBxetc9ZDuhHj5uc0HP0Pd=ebqNdJ-_Mg at mail dot gmail dot com> <m3wqjize2h dot fsf at sspiff dot org>
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