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

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Paul" == Paul Pluzhnikov <ppluzhnikov@google.com> writes:

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

Recently a new problem occurred to me.  When gdb is multi-process, we
may have one inferior using libstdc++.so.5 and another using
libstdc++.so.6.  Since pretty-printing is currently done strictly by
type name, this will cause clashes.

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

Thanks, I didn't think of this case.

One idea that would solve this problem and the inferior clash problem
would be to tie the pretty-printers to some sort of objfile signature.
The idea would be that a pretty-printer will only be considered if the
inferior from which the value comes uses the printer's objfile.

I don't know exactly how we'd compute this signature, but I assume
however we do it for debug info right now -- though I think that is a
Fedora-specific patch.

This would imply having some kind of module name management on the
python side, as well.  That is, ideally libstdc++ maintainers would
not have to rename all their python printers when bumping the .so
version.  I don't know enough to know what is feasible here.

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

I considered this, but opted against it for two reasons.  First, the
current approach is simpler.  Second, I thought a purely file-based
approach might interact better with the Python module system.

I'm not averse to experimentation, though.  Feel free to make a branch
and try it out :-)

I've been thinking about solving the clash problem by putting the
python code for an objfile into a subdirectory, named after the
objfile somehow.  For libraries we could encode the version number in
the name.  This would solve the name clash problem, provided the
objfile-to-directory mapping is designed properly.  I think it would
also work ok with separate debug info.

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

Yeah.  I haven't thought about this problem.  But, it does happen, so
I think we ought to solve it.

I suppose we could just require executables using such libraries to
declare them in their own ".gdb.py".  This could work if the library
package installed its printers in the right place.

Paul> - Once everything looks good, developer appends something like:
Paul>    #pragma embed_source(".gdb_py", "./SomeClass.py")
Paul>   to SomeClass.cc, and gcc does the rest.

I'd prefer an approach that doesn't involve changes outside of gdb.
But, I suppose this could solve the pure-header-library problem as well.

Tom