From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3133 invoked by alias); 23 Mar 2011 09:06:18 -0000 Received: (qmail 3123 invoked by uid 22791); 23 Mar 2011 09:06:16 -0000 X-SWARE-Spam-Status: No, hits=-0.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,TW_BJ,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org Received: from mail-vx0-f169.google.com (HELO mail-vx0-f169.google.com) (209.85.220.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 23 Mar 2011 09:06:10 +0000 Received: by vxk12 with SMTP id 12so7659638vxk.0 for ; Wed, 23 Mar 2011 02:06:08 -0700 (PDT) Received: by 10.220.14.132 with SMTP id g4mr1513981vca.27.1300871168332; Wed, 23 Mar 2011 02:06:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.200.3 with HTTP; Wed, 23 Mar 2011 02:05:48 -0700 (PDT) In-Reply-To: References: From: Kevin Pouget Date: Wed, 23 Mar 2011 09:06:00 -0000 Message-ID: Subject: Re: Python objfile-gdb.py file -- how to handle reloading properly ? To: gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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: 2011-03/txt/msg00130.txt.bz2 Hello, I'm not writing a pretty-printer, but something quite similar to thread-event notification (eg, thread creation/death, where some special locations are breakpointed, and an action is trigger upon hitting the bp). So in this case, maybe the autoloading discussed before is not actually the best solution. What I would like to do is: > (at gdb startup) Load the process-independent part of my --python-- module > (at application startup/shared library loading) Set my breakpoint, resolv= e addresses and enable process-dependent commands -- AFAIU, that's more or less what was done with linux-thread-db.c and libpthread.so -- whereas currently, I just load everything from the objfile-gdb.py hook Cordially, Kevin On Tue, Mar 22, 2011 at 1:00 PM, Tom Tromey wrote: > > >>>>> "Kevin" =3D=3D Kevin Pouget writes: > > Kevin> I'm playing with the objfile-gdb.py loading, and I can't manage to > Kevin> support the reloading efficiently: > [...] > Kevin> which looks like a ugly hack! Did you find any better solution? > > Yeah, have your hook file be very small and have it import the real > printers. =A0The documentation lays out the best approach: > > =A0 =A0 =A0 We recommend that you put your core pretty-printers into a Py= thon > =A0 =A0package. =A0If your pretty-printers are for use with a library, we > =A0 =A0further recommend embedding a version number into the package name. > =A0 =A0This practice will enable GDB to load multiple versions of your > =A0 =A0pretty-printers at the same time, because they will have different > =A0 =A0names. > > =A0 =A0 =A0 You should write auto-loaded code (*note Auto-loading::) such= that it > =A0 =A0can be evaluated multiple times without changing its meaning. =A0A= n ideal > =A0 =A0auto-load file will consist solely of `import's of your printer > =A0 =A0modules, followed by a call to a register pretty-printers with the > =A0 =A0current objfile. > > =A0 =A0 =A0 Taken as a whole, this approach will scale nicely to multiple > =A0 =A0inferiors, each potentially using a different library version. > =A0 =A0Embedding a version number in the Python package name will ensure = that > =A0 =A0GDB is able to load both sets of printers simultaneously. =A0Then, > =A0 =A0because the search for pretty-printers is done by objfile, and bec= ause > =A0 =A0your auto-loaded code took care to register your library's printers > =A0 =A0with a specific objfile, GDB will find the correct printers for the > =A0 =A0specific version of the library used by each inferior. > > Tom