On Wed, 2013-08-21 at 15:01 -0600, Tom Tromey wrote:
> >>>>> "David" == David Malcolm <dmalc...@redhat.com> writes:
[...]

> David> How would one go about toggling the enabledness of a prettyprinter?  Is
> David> this something that can only be done from python?
> 
> You can use "enable pretty-printer" and "disable pretty-printer".

Yes, using .* to match the current executable:

  (gdb) disable pretty-printer .* gcc
  7 printers disabled
  128 of 135 printers enabled

and this does indeed disable/enable the prettyprinters.


> David> I did see references to gdb.parameter("verbose") in gdb.printing
> David> - how would one go about setting this?
> 
> "set verbose on"
> 
> I think few people use this setting though; probably best to do what
> you're doing now.
> 
> David> +# Convert "enum tree_code" (tree.def and tree.h) to a dict:
> David> +tree_code_dict = gdb.types.make_enum_dict(gdb.lookup_type('enum 
> tree_code'))
> 
> One other subtlety is that this doesn't interact well with all kinds of
> uses of gdb.  For example if you have a running gdb, then modify enum
> tree_code and rebuild, then the pretty-printers won't notice this
> change.
> 
> I guess it would be nice if we had pre-built caches for this kind of
> this available upstream.  But meanwhile, if you care, you can roll your
> own using events to notice when to invalidate data.

As they say, the two fundamental problems in Computer Science are cache
invalidation, naming things, and off-by-one errors.

I'm inclined not to care for now: if you've rebuilt gcc with a new enum
tree code, then you should restart gdb.

Is there a precanned event provided by gdb that I can connect to for
when the underlying code has changed and my caches need to be
invalidated?


> David> +    def __call__(self, gdbval):
> David> +        type_ = gdbval.type.unqualified()
> David> +        str_type_ = str(type_)
> 
> FWIW I think for RegexpCollectionPrettyPrinter you could write a
> subclass whose __call__ first dereferenced a pointer, then called
> super's __call__.  But your approach is just fine.

Thanks

Reply via email to