From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24646 invoked by alias); 7 May 2013 13:28:14 -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 24636 invoked by uid 89); 7 May 2013 13:28:13 -0000 X-Spam-SWARE-Status: No, score=-7.6 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_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; Tue, 07 May 2013 13:28: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 r47DS88b020740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 May 2013 09:28:08 -0400 Received: from localhost.localdomain (ovpn-112-21.ams2.redhat.com [10.36.112.21]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r47DS6IO012451; Tue, 7 May 2013 09:28:07 -0400 Message-ID: <51890165.3070701@redhat.com> Date: Tue, 07 May 2013 13:28:00 -0000 From: Phil Muldoon MIME-Version: 1.0 To: =?ISO-8859-1?Q?Marc_Br=FCnink?= CC: gdb Subject: Re: Timer References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SW-Source: 2013-05/txt/msg00038.txt.bz2 On 06/05/13 10:52, Marc Brünink wrote: > I want to execute a piece of code at regular intervals. Actually I'm sampling $pc. > (let's not go into detail why I use gdb) > > My current solution just starts another process that sends a SIGTRAP to the debugged application. Using a simple script I can print the $pc. > > However, I just realised that this approach does not work too well. If gdb is stopped due to a breakpoint it will interpret the received SIGTRAP as another hit of the very same breakpoint. > > Reproduce: > 1. Attach to any program > 2. Create any breakpoint > 3. Wait until breakpoint is hit > 5. continue You can a little of this right now with the GDB Python API by writing a breakpoint in Python that implements the "stop" callback. I know you mentioned only within the confines of GDB, but the Python API is provided as standard (of course, you have to have Python installed on the system). From: http://sourceware.org/gdb/current/onlinedocs/gdb/Breakpoints-In-Python.html#Breakpoints-In-Python class MyBreakpoint(gdb.Breakpoint): def stop(self): pc = gdb.parse_and_eval("(long) $pc") print "0x"+long(pc).__format__("x") return False b = MyBreakpoint("foo.c:42") In the "stop" callback, if the callback returns "False", the inferior is continued (if "True", the inferior is stopped). If you wanted to make the breakpoint depend on the state of the inferior, you can use the Breakpoint.condition string to insert a condition. > 4. Send SIGTRAP to debugged application But I am not sure what this relates to a timer event, so I am probably not fully understanding what you want. There are two other areas of the Python API which may interest you: Events in GDB/Python: http://sourceware.org/gdb/current/onlinedocs/gdb/Events-In-Python.html#Events-In-Python And inserting objects into GDB's event loop gdb.post_event() http://sourceware.org/gdb/current/onlinedocs/gdb/Basic-Python.html#Basic-Python Unfortunately post_event() is not deterministic. The callable object is called when GDB gets around to processing that event in the queue. There is no way to arbitrarily run an event according to a timer, at least in the Python API; it is event based only (right now). Cheers, Phil