From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24254 invoked by alias); 11 Jun 2009 08:29:12 -0000 Received: (qmail 24243 invoked by uid 22791); 11 Jun 2009 08:29:11 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,SARE_LWSHORTT,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 11 Jun 2009 08:29:05 +0000 Received: (qmail 32515 invoked from network); 11 Jun 2009 08:29:03 -0000 Received: from unknown (HELO wind.localnet) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 11 Jun 2009 08:29:03 -0000 From: Vladimir Prus To: tromey@redhat.com Subject: Re: Registering pretty-printers Date: Thu, 11 Jun 2009 08:29:00 -0000 User-Agent: KMail/1.11.90 (Linux/2.6.24-24-generic; KDE/4.2.90; i686; svn-979530; 2009-06-10) Cc: gdb@sources.redhat.com References: <200906080310.58102.vladimir@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200906111229.04020.vladimir@codesourcery.com> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-06/txt/msg00107.txt.bz2 On Wednesday 10 June 2009 Tom Tromey wrote: > >>>>> "Vladimir" == Vladimir Prus 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 >