Re: [PATCH] Debug Methods in GDB Python

[Doug Evans <xdje42@gmail.com>]

On Fri, Dec 6, 2013 at 3:24 PM, Siva Chandra <sivachandra@google.com> wrote:
> 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?

Not sure I understand the question.

> 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.

That's a good point.

Part of the reason for a grouping is that one can then have the list
of all methods usefully sorted.
One would want to see all the libstdc++ debug methods listed together
and then within that one would want to see all the debug methods for a
particular class/template listed together.
Sorting by objfile is easy of course, that's how they're recorded.
Within an objfile it would depend on how debug methods are registered.
In pretty-printer land "one" pretty-printer can actually be a
collection of several within it.
Thus in order to enable/disable individual printers we need to be able
to specify the top level object and then the printer within it.

e.g.

(gdb) disable pretty .*libstd.* libstdc[+][+]-v6;.*vector.*
5 printers disabled
123 of 128 printers enabled

A bit awkward, granted, (eg. having to deal with + in libstdc++).

Anyways, using naming convention sounds reasonable to me for version 1.
[Though if the names get kinda long, splitting them up as you have
with group name and debug method name does become appealing.
If "group name" was intended to be, or include, the class name,
apologies!  I didn't see it. :-(]


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

Yep.  Totally understand.