[patch] Fix glitches with libstdc++ pretty printers

[Paul Pluzhnikov]

On Mon, Dec 22, 2008 at 2:26 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Paul" == Paul Pluzhnikov <ppluzhnikov@google.com> writes:
>
> Paul> Hmm, an easy way to solve this would be to say that if Foo inherits
> Paul> from Bar, and if Bar has a pretty-printer but Foo doesn't, then
> Paul> the Bar pretty-printer is used.
>
> Paul> With that, I only need to define one pretty-printer :)
>
> This same problem came up in the GObject context.
>
> I do wonder whether regexp on the type name is the best way to
> associate types with printer constructors.
>
>
> One idea I had was that the -gdb.py code could iterate over the types
> defined in the current objfile and set up the dictionary using the
> results.  We'd have to write some more Python glue to make this
> possible, but we'll need that anyway.
>
> This would let you implement printing-via-inheritance.  We could even
> supply a utility function to make it simple.
>
> The down side of this approach is that (I think) it requires loading
> the symbols, which interacts poorly with the lazy-reading branch,
> which we also want.
>
>
> Another idea is to run a hook when a type is created, and do the
> association directly, not by name.  My worry here is that we'd see a
> noticeable performance hit.

In a given GDB session, a great majority of types will not be
examined by the end-user, so it seems wasteful to examine type
hierarchies and create pretty-printers for the types which will
never be accesses.

It appears to me that the current "on demand" solution is better.

> Finally, you can do it already, with a bit of difficulty.  You can
> install a printer constructor for any struct type, and then have it
> examine the type hierarchy.

Except (AFAICT) gdb.Type doesn't (yet) give access to ancestors.
So I believe I can't do it this way just yet.

The other difficulty is that (in C++) the type is (somewhat
unintuitively) called '^Foo$' (unlike C, where it is called
'^struct Foo$'), so I'd have to examine every possible type, not
just structs.

> If the desired ancestor is not found, it
> can return None, and the C code will look for the next printer.  You
> can even register the newly discovered type in the map for faster
> access the next time.
>
> I imagine this is pretty slow, but I have not tried it.  I think it
> would be preferable to come up with something nicer if we can.
>
> Right now I'm not sure what exactly I want to do.  Gathering
> requirements is always a good first step...
>
> Tom
>

I've implemented the "automatically recursively search ancestors"
solution (patch attached), and will "unleash" it on my users.

We'll know in about a month how well (or how poorly) this works here.

Thanks,
-- 
Paul Pluzhnikov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Recursive-search-for-pretty-printers.patch
Type: text/x-patch
Size: 2337 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/archer/attachments/20081222/dfe5fded/attachment.bin>