This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Registering pretty-printers
On Wednesday 10 June 2009 Tom Tromey wrote:
> >>>>> "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.
Oh, I actually did not know about this hook (objname-gdb.py, right?).
Now that I've read about it, I will be able to better explain my
concerns.
> 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.
To begin with, this works only if there's linking. Say, I want to
provide pretty-printers for the Boost C++ Libraries. There's about 90
of individual libraries, and only 10 or so are actually compiled. A
user application might not use any of those 10, so there's no objfile
at all, ever.
> 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.
I think it's generally wrong to assume that pretty-printers are either:
1. Always distributed with the library they provide pretty-printing for
2. Are associated with any separately compiled code.
Therefore, we should make up some conventions how a pretty-printer can
be packaged separately, preferably as a single file, and how IDE,
given name of the file and nothing else, can enable pretty printing.
Say, how about tar.gz, which is unpacked by IDE, whose top-level
directory is added to PYTHONPATH, and which should have top-level
file called init.py, with a function 'init_pretty_printers'?
> 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.
I suspect you approach this from a bit of Fedora-centric approach. You
can easily transition important libraries to using pretty-printers,
or provide updates should pretty-printers be modified. IDE developers
have no luxury to assume that libraries users care about will be updated
in any time frame.
- Volodya
>
> Tom
>