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

["Paul Pluzhnikov" <ppluzhnikov at google dot com>]

On Wed, Oct 15, 2008 at 4:48 PM, Tom Tromey <tromey@redhat.com> wrote:

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

As you pointed out, this may break if e.g. libstdc++.so.5,
libstdc++.so.6 and libfancy_container.so.1 are all in /lib, there
is no separate debuginfo, and all 3 libraries "fight" for /lib/.gdb.py.

Also, if a newer binary is installed, but the .gdb.py file isn't,
things break as well (Microsoft .PDB files have this inconvenient
property).

The approach I am considering is to put python pretty printing
code into ".gdb_py" section in the object file which implements
the "guts" of a container, and for GDB to automatically python-source
this section when the object is loaded.

Obviously this only works for object file formats which are flexible
enough to have multiple named sections, such as ELF.

There is also a question of what to do about containers that are
implemented entirely in a header file.

Ignoring the 2 issues above for the moment, I expect the following
"use case" to work well here at Google:

- Developer implements SomeClass for which a pretty-printer is
  desired.

- As developer debugs it, he writes SomeClass.py to pretty print it,
  and loads that manually into GDB.

- Once everything looks good, developer appends something like:

   #pragma embed_source(".gdb_py", "./SomeClass.py")

  to SomeClass.cc, and gcc does the rest.

  [This #pragma is just for convenience, so developer doesn't have
   to (painfully) reformat the Python source into

    __asm__ (".section .gdb_py\n"
            "\t.string \"class StdListPrinter:\"\n"
	    ...);

    Alternatively, an objcopy could be used to add .gdb_py section
    to SomeClass.o]

  When multiple objects are linked into DSO or an executable,
  linker will merge all .gdb_py sections, so you get pretty printers
  for all the containers actually used.


Comments?
-- 
Paul Pluzhnikov