Re: [patch] Fix glitches with libstdc++ pretty printers

[Tom Tromey <tromey at redhat dot com>]

Tom> I guess I could check this in temporarily so we could share.

Paul> Perhaps this can go into testsuite/gdb.python/python-stl.py ?

Paul> That's where I put it as I was working up a test case.

I think I'd prefer a standalone test suite -- one not relying on
any details of libstdc++.  That way, if libstdc++ changes, our test
suite won't have to.

Paul> The question of "who and how should maintain this" is an interesting
Paul> one. Ideally you'd want container writers to do that, and you'd want
Paul> this code to be somehow embedded in the binary with the rest of
Paul> debug info, so the end user can pretty print any container and not
Paul> worry about the pretty printer getting out of sync with container
Paul> implementation. But I have no clue how to achieve this :(

This already works!  :-)

When gdb opens a new objfile, it will look for a ".gdb.py" in the
objfile's directory.  If it exists, it is passed to Python.
This setup also works fine with separate debug info.

I'm not 100% happy with this approach.  It works great if you assume
separate debug info.  But, if you have a more traditional setup, you
only get one .gdb.py per directory -- not super.

So, some refinement is needed.  Let me know what you think.

If you already have your own GCC built, it is very easy to see this in
action.  Just copy the pretty-printer to $prefix/lib/.gdb.py.  Then,
debug a program that is linked to that libstdc++.  When I do this, the
pretty-printers are made available once the inferior loads libstdc++.

I'll probably try to get these printers into libstdc++ at some point.
Exactly how or when depends a bit on when we think the python API is
stable and the ship date of a gdb with the necessary features.

If we wanted to market this a bit, we could write printers for a
variety of free software projects.

>> class StdListPrinter:
>> "Print a std::list"

Paul> I think this either depends on some uncomitted patches, or else is
Paul> broken for nested STL containers:

Thanks, I'll look at this tomorrow.
I probably broke something... now the test suite is officially overdue.

Tom