From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13805 invoked by alias); 5 Feb 2010 01:52:57 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 13796 invoked by uid 22791); 5 Feb 2010 01:52:56 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org From: Tom Tromey To: David Malcolm Cc: Project Archer Subject: Re: Inferior python debugging: working prototype References: <1265327904.8892.56.camel@brick> Reply-To: Tom Tromey Date: Fri, 05 Feb 2010 01:52:00 -0000 In-Reply-To: <1265327904.8892.56.camel@brick> (David Malcolm's message of "Thu, 04 Feb 2010 18:58:24 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2010-q1/txt/msg00067.txt.bz2 David> I've now got working gdb python code for prettyprinting the various David> types seen when the inferior process is linked against libpython, such David> as for debugging the python binary itself (or presumably a build of gdb David> itself, though I haven't tried that). Very cool. David> I am still seeing the issue described in that post where variables of David> interest are visible from within the regular (gdb) interface, but not David> visible from python's gdb.selectedframe.read_var() (specifically, the David> PyFrameObject *f within PyEval_EvalFrameEx; which appears to be an issue David> with an inlined frame of C code). Could you file this in bugzilla? If it works from the CLI then there should be some way to access it from Python. David> - I want the prettyprinter hooks to be used by default on Python David> backtraces in Fedora 13, so that (for example) automated tools that David> capture backtraces contain this rich debugging information. What's the David> best way of wiring this up so that the module is imported? Is something David> like this happening for the GLib/GTK hooks, or for the STL? See the Auto-loading and Selecting Pretty-Printers nodes in the manual. I think they describe it fairly well. The libstdc++ printers are all set up to work this way. If you read the libstdc++ "hook file", it is full of a lot of goo you may not need, because upstream GCC wants its install tree to be relocatable. If you don't care about that you can shrink the file down to a couple of lines. David> - should this be distributed as part of gdb or part of python? (it David> handles both python2 and python3, mostly, at any rate) Ideally, IMO, with Python. In general I think the only way to scale this up to lots of libraries is to maintain the custom code alongside its project. Right now, in Fedora, we are distributing the libstdc++ printers in the gdb RPM, but I think (hope) we will be changing that. I don't really remember the detailed reason for this decision, but basically it was expediency. David> - I'd like to be able to automatically test this. Am I right in David> thinking that it's reasonable to assume that given that a gdb configured David> with --with-python can also be tested debugging that instance of python David> (I'd also like to automate testing of python3 support, which would be a David> different runtime) I'm not sure I understand the potential issue. There should be no problem using python-enabled gdb with these printers to debug a second instance of itself, or of any other program using python. David> - to what extent is a pretty-printer expected to return in a David> sane amount of time and use sane amounts of RAM? What I recommend is trying to write your printers so that they work lazily. That is, don't precompute the proxy objects, have your printer's children method return an iterator that computes them lazily. GDB will only ask for the children it intends to print, as determined either by user settings in the CLI (e.g., "set print elements") or by UI requests to limit the number of varobj children in MI. This may not always be easy; if it really isn't possible I am not sure what you could do. The problem is that if your printer limits the output, there is no way to request more. Tom