From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30137 invoked by alias); 12 Apr 2013 10:39:15 -0000 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 Received: (qmail 30126 invoked by uid 89); 12 Apr 2013 10:39:14 -0000 X-Spam-SWARE-Status: No, score=-8.2 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 12 Apr 2013 10:39:13 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r3CAdB1c001020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 12 Apr 2013 06:39:12 -0400 Received: from localhost.localdomain (ovpn-116-94.ams2.redhat.com [10.36.116.94]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r3CAdA0Q025018; Fri, 12 Apr 2013 06:39:10 -0400 Message-ID: <5167E44D.7050109@redhat.com> Date: Fri, 12 Apr 2013 10:39:00 -0000 From: Phil Muldoon MIME-Version: 1.0 To: Nick Bull CC: gdb@sourceware.org Subject: Re: Spotting inferior function calls from Python References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-04/txt/msg00032.txt.bz2 On 05/04/13 12:48, Nick Bull wrote: > Hi, > > I would like my Python code to be notified when gdb causes a function to be > run on the inferior outside of the normal program flow. For example, this > could be used to warn the user that any side-effects might change future > program execution. > > I can't simply hook the 'call' command because there are many other > commands which could in principle invoke inferior functions, and too many > false positives would be inconvenient. > > It looks as though all such function calls happen via > call_function_by_hand. So the simplest approach would be for me to create a > new observer type which is notified in call_function_by_hand, and a > corresponding Python event type. Does that sound sensible? I think all inferior function calls go through call_function_by_hand. However inferior function calls can happen in lots of places in GDB, not just via the call CLI command. Another question to think about is when do you trigger the event? Before the dummy frame is constructed? After the inferior function call has executed? After the dummy frame has been constructed but before the function call has been executed? These are important as they will affect the call stack. If you created the event after the dummy frame has been created, but before the inferior function call has been executed, there will be a dummy frame in your call stack. Will that affect the Python user, or, in your example, your use case? Some examples of inferior function calls are: - When an expression is evaluated. If an expression contains a call into the inferior, then the inferior function call is completed when the expression is evaluated. E.g, (gdb) p foo(). The "foo()" bit is evaluated by the print command which leads to the inferior function call. This applies to things like conditional breakpoints, and any command that takes and evaluates an expression. - The direct "call" command. - via Python API gdb.parse_and_eval(). This hooks into the same evaluation engine as the first point. - Via the gdb.Value() callable interface (when a gdb.Value represents a pointer to a function). There are probably more. But the point is you cannot usefully delineate or categorize where the call originates from for usage purposes. You have to catch them all. However, from the point of view of Python I don't think that matters; provide the observer -> observable and let the (user provided) Python code either act or ignore it. > And is such a patch likely to be accepted for inclusion, assuming all > formatting and copyright assignment requirements are met? Nobody can say. And I am not a maintainer, so I don't speak for that group. But I think I can confidently say that if you submit a patch it will be constructively reviewed in a positive and impartial manner. If there are problems, or the maintainers disagree about implementation, then you will be expected to argue your point convincingly or make the changes. I have submitted many patches, and not once have I ever felt unfairly dealt with. It has all been positive. Cheers, Phil