Re: Registering pretty-printers

[Tom Tromey <tromey@redhat.com>]

>>>>> "Vladimir" == Vladimir Prus <vladimir@codesourcery.com> writes:

Vladimir> I have a concern about the way Python pretty-printers seem
Vladimir> to work now.  To register a pretty-printer, one is supposed
Vladimir> to do this (according to
Vladimir> http://permalink.gmane.org/gmane.comp.debugging.archer/1352)

Vladimir> 	import sys
Vladimir> 	sys.path.insert(0, 'XXX')
Vladimir> 	from libstdcxx.v6.printers import register_libstdcxx_printers
Vladimir> 	register_libstdcxx_printers (None)

Just to be clear -- the context here is a user checking out just the
python printers from the gcc repository.  The gyrations are needed
because the usual hook file is processed by configure, and so isn't
available if you do a limited checkout like this.  So, you get to
reproduce it by hand somehow.

Vladimir> This seem to contain quite a lot of information that is
Vladimir> specific for given pretty printer -- like the package name,
Vladimir> and the name of function to register pretty-printers. Some
Vladimir> other project might have package named boost and function
Vladimir> called register_boost_printers, and some other package might
Vladimir> use something else. As result, it is not possible to IDE
Vladimir> user to just point at directory and have pretty-printers
Vladimir> loaded. Can we maybe require that the __init__ module does
Vladimir> registration?

I don't understand how this would work.


My thinking behind the current plan is that it is ok for gdb to fix
file names, but not Python module names.  I thought it was acceptable
to require a specific hook file name computed from an objfile's name,
but it was not acceptable to compute the Python module name from the
objfile's name.  Partly that is because objfile names cannot clash.

The hook file is re-read every time the objfile is created.  This is
needed because an object may be loaded and unloaded several times,
creating a new objfile each time.

Finally, we recommend that the hook file import the actual printer
implementations and install them on the objfile.  Furthermore, we
recommend putting some kind of version number into the namespace name
(the "v6" in the libstdc++ example).  The reason for these things is
future-proofing printers for multi-process -- the import means that
the printers are not re-created over and over each time the objfile is
created, and the versioning means that we can properly handle multiple
inferiors, each using a different version of a given library.


I realize this is all very shared-library- (aka distro-) centric.  It
works very well when all the bits are packaged nicely: python hook
files installed alongside libraries, etc.

It works less well in a couple of reasonably common scenarios:

1. Static linking.  Lookups are done by objfile, but with static
linking the distinctions are erased.

2. Users who have an old version of a library but who want to tack on
the pretty-printers.


I'm not really sure what to do in these cases.

For case #1, one idea is to punt the problem to the IDE.  An IDE could
presumably arrange to invoke the hook files for the static libraries
used by a given link.

I don't find this a particularly satisfactory solution, but I don't
have other ideas.  I think someone who uses static linking regularly
(I do not) would probably be better suited to come up with a solution.


For case #2 ... to me this seems like a short term problem, so I have
not been worrying about it much.  We could put a HOWTO on the wiki,
for example.  That would suffice for many users.

Tom