From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3485 invoked by alias); 10 Jun 2009 19:25:36 -0000 Received: (qmail 3437 invoked by uid 22791); 10 Jun 2009 19:25:35 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,SARE_LWSHORTT,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 10 Jun 2009 19:25:29 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n5AJPRAM032123 for ; Wed, 10 Jun 2009 15:25:27 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n5AJPRLj016337 for ; Wed, 10 Jun 2009 15:25:27 -0400 Received: from opsy.redhat.com (vpn-13-36.rdu.redhat.com [10.11.13.36]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n5AJPQQ9027184; Wed, 10 Jun 2009 15:25:27 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 3C15B37817A; Wed, 10 Jun 2009 13:25:26 -0600 (MDT) To: Vladimir Prus Cc: gdb@sources.redhat.com Subject: Re: Registering pretty-printers References: <200906080310.58102.vladimir@codesourcery.com> From: Tom Tromey Reply-To: tromey@redhat.com Date: Wed, 10 Jun 2009 19:25:00 -0000 In-Reply-To: <200906080310.58102.vladimir@codesourcery.com> (Vladimir Prus's message of "Mon\, 8 Jun 2009 03\:10\:57 +0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00093.txt.bz2 >>>>> "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. 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