From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5041 invoked by alias); 30 Nov 2012 14:30:58 -0000 Received: (qmail 5012 invoked by uid 22791); 30 Nov 2012 14:30:56 -0000 X-SWARE-Spam-Status: No, hits=-5.9 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SARE_TOWRITE,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 30 Nov 2012 14:30:48 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qAUEUl62019816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 30 Nov 2012 09:30:47 -0500 Received: from localhost.localdomain (ovpn-116-27.ams2.redhat.com [10.36.116.27]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qAUEUhng032128 for ; Fri, 30 Nov 2012 09:30:46 -0500 Message-ID: <50B8C313.2070404@redhat.com> Date: Fri, 30 Nov 2012 14:30:00 -0000 From: Phil Muldoon MIME-Version: 1.0 To: "gdb-patches@sourceware.org" Subject: [patch][python] 0 of 5 - Frame filters and Wrappers Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-11/txt/msg00925.txt.bz2 This patch introduces the concept of frame filters, and frame wrappers to GDB. This is a Python API that enables users to filter, sort, elide and decorate frames that some GDB commands produce. The commands affected are: * backtrace command * -stack-list-frames * -stack-list-locals * -stack-list-arguments * -stack-list-variables Note the MI commands have to be enabled with the -enable-frame-filters command first. This is because we include a new field called "children" in some situations. This patch is split up into several sections due to its length. Each patch email has a subject line indicating the contents of that patch. In total, there are five patch emails, not including this one. Non Python enabled GDB ====================== If your GDB build is configured not to build the Python API, then there will be no changes visible to you. GDB backtraces will be printed as they always have. Python enabled GDB ================== In the case of a Python enabled GDB, each command has a switch to turn off frame filters*, and MI has to have frame filters enabled explicitly first. I have not provided a CLI command to turn off the feature on a one-time-basis, but will if it is deemed necessary. * Frame filters on individual MI commands are turned off with --no-frame-filters. With the "bt" command, they are turned off with the raw sub-command (e,g "bt raw"). This is inconsistent at the moment, and I expect it will be resolved in review. "raw" is overloaded, but I am at a loss to what to call the sub-command. MI is easy as it is a machine interface, so length of the option is not an issue. Notes ===== * Printing My original approach was to create dummy frames from the original frames and decorating objects, and print those via the existing CLI routines. However this brought up a number of issues. Creating dummy frames and printing them disrupts the integrity of the call stack, and affects how frame navigation is performed (IE, select, or in the case of Python gdb.selected_frame, gdb.newest_frame, and so on). Also creating fully coherent and operating dummy frames, with their associated architectures, registers, and other ancillary structures turned out to be incredibly complex. I decided instead to approach the problems as "a frame and a decorator object" approach. This would have still allowed some use of code, but the ongoing practice of avoiding stubbing in: #ifdef HAVE_PYTHON into the non-Python areas of GDB code indicates we should do that as little and sparingly as possible. So I just decided to write the routines in the Python section of the GDB codebase. * Python errors when printing? Right now if there is an error encountered, the frame printing is aborted and GDB falls back to its own inbuilt printing routines. This is up for debate, and I hope it sparks a discussion. If the GDB Python API encounters an error while printing a backtrace, should it: - Abandon the whole backtrace, and have the existing GDB code print it; - Abandon that frame, and continue on; * Shipping frame filters The current frame filter code will not trigger a Python enabled frame filter produced backtrace if there are no frame filters registered. In this case it just defers to the existing GDB frame printing code. As there are no Python-written frame filters shipped with FSF GDB, this will be the default case. And if there ever are any, they will be subject to the usual review policy. Cheers, Phil