* Timer @ 2013-05-06 9:52 Marc Brünink 2013-05-07 4:43 ` Timer Doug Evans 2013-05-07 13:28 ` Timer Phil Muldoon 0 siblings, 2 replies; 8+ messages in thread From: Marc Brünink @ 2013-05-06 9:52 UTC (permalink / raw) To: gdb; +Cc: marc 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 4. Send SIGTRAP to debugged application 5. continue Actually, now that I think about it, I should have anticipated this behaviour. Is there a better way to execute a piece of code at regular intervals? Marc From gdb-return-42099-listarch-gdb=sources.redhat.com@sourceware.org Mon May 06 17:12:03 2013 Return-Path: <gdb-return-42099-listarch-gdb=sources.redhat.com@sourceware.org> Delivered-To: listarch-gdb@sources.redhat.com Received: (qmail 9572 invoked by alias); 6 May 2013 17:12:03 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb.sourceware.org> List-Subscribe: <mailto:gdb-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb/> List-Post: <mailto:gdb@sourceware.org> List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-owner@sourceware.org Delivered-To: mailing list gdb@sourceware.org Received: (qmail 9560 invoked by uid 89); 6 May 2013 17:12:02 -0000 X-Spam-SWARE-Status: No, score=-7.0 required=5.0 tests=AWL,BAYES_00,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; Mon, 06 May 2013 17:12:02 +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 r46HBua3025203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=OK); Mon, 6 May 2013 13:11:56 -0400 Received: from barimba (ovpn-113-163.phx2.redhat.com [10.3.113.163]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r46HBtp1019867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits\x128 verify=NO); Mon, 6 May 2013 13:11:55 -0400 From: Tom Tromey <tromey@redhat.com> To: Joel Brobecker <brobecker@adacore.com> Cc: "Miguel A. G L" <miguelnum@gmail.com>, gdb@sourceware.org Subject: Re: How I can force "gdb" for internal use command-messages only in English? References: <CAAZ-Otu15DunhUQ_qc2TvB6mXr40TsfADk2iCX1jNmhjBGJL3Q@mail.gmail.com> <20130502054104.GH3525@adacore.com> Date: Mon, 06 May 2013 17:12:00 -0000 In-Reply-To: <20130502054104.GH3525@adacore.com> (Joel Brobecker's message of "Thu, 2 May 2013 09:41:04 +0400") Message-ID: <87wqrcyqw5.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2013-05/txt/msg00026.txt.bz2 Content-length: 717 >>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes: >> Basically the problem occurs because some commands that sends "gdb" to >> the IDE are translated into "Spanish" and the IDE looks texts these >> commands in English. Joel> If Lazarus is depending on the language used by GDB to be English, Joel> it sounds like Lazarus should override the user's environment in Joel> terms of i18n. Typically, the language is determined via the LANG Joel> and/or LC_* environment variables, so it should be able to force Joel> English by setting LANG/LC_ALL et al to Eg. "C" before starting GDB. I just wanted to mention that it would be even better to change Lazarus to use MI. This is what MI was made for. Tom ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Timer 2013-05-06 9:52 Timer Marc Brünink @ 2013-05-07 4:43 ` Doug Evans 2013-05-07 6:42 ` Timer Marc Brünink 2013-05-07 13:28 ` Timer Phil Muldoon 1 sibling, 1 reply; 8+ messages in thread From: Doug Evans @ 2013-05-07 4:43 UTC (permalink / raw) To: Marc Brünink; +Cc: gdb On Mon, May 6, 2013 at 2:52 AM, Marc Brünink <marc@nus.edu.sg> 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 > 4. Send SIGTRAP to debugged application > 5. continue > > Actually, now that I think about it, I should have anticipated this behaviour. > Is there a better way to execute a piece of code at regular intervals? bash$ man setitimer ? ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Timer 2013-05-07 4:43 ` Timer Doug Evans @ 2013-05-07 6:42 ` Marc Brünink 2013-05-07 8:48 ` Timer Pedro Alves 0 siblings, 1 reply; 8+ messages in thread From: Marc Brünink @ 2013-05-07 6:42 UTC (permalink / raw) To: Doug Evans; +Cc: gdb On May 7, 2013, at 12:43 PM, Doug Evans wrote: > On Mon, May 6, 2013 at 2:52 AM, Marc Brünink <marc@nus.edu.sg> 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 >> 4. Send SIGTRAP to debugged application >> 5. continue >> >> Actually, now that I think about it, I should have anticipated this behaviour. >> Is there a better way to execute a piece of code at regular intervals? > > bash$ man setitimer I suppose you are suggesting to modify either GDB or the application. This is exactly what I don't want. Any other way to accomplish this (using gdb)? Marc From gdb-return-42104-listarch-gdb=sources.redhat.com@sourceware.org Tue May 07 07:33:38 2013 Return-Path: <gdb-return-42104-listarch-gdb=sources.redhat.com@sourceware.org> Delivered-To: listarch-gdb@sources.redhat.com Received: (qmail 32724 invoked by alias); 7 May 2013 07:33:38 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb.sourceware.org> List-Subscribe: <mailto:gdb-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb/> List-Post: <mailto:gdb@sourceware.org> List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-owner@sourceware.org Delivered-To: mailing list gdb@sourceware.org Received: (qmail 32653 invoked by uid 89); 7 May 2013 07:33:37 -0000 X-Spam-SWARE-Status: No, score=-4.6 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL autolearn=ham version=3.3.1 Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 07 May 2013 07:33:36 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1UZcP1-0005rE-1r from Yao_Qi@mentor.com ; Tue, 07 May 2013 00:33:35 -0700 Received: from SVR-ORW-FEM-04.mgc.mentorg.com ([147.34.97.41]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 May 2013 00:33:35 -0700 Received: from qiyao.dyndns.org (147.34.91.1) by svr-orw-fem-04.mgc.mentorg.com (147.34.97.41) with Microsoft SMTP Server id 14.2.247.3; Tue, 7 May 2013 00:33:33 -0700 Message-ID: <5188AE42.50308@codesourcery.com> Date: Tue, 07 May 2013 07:33:00 -0000 From: Yao Qi <yao@codesourcery.com> User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Suchakra Sharma <suchakrapani.sharma@polymtl.ca> CC: <gdb@sourceware.org>, <simon.marchi@polymtl.ca> Subject: Re: Debugging agent library References: <1367868074.5194.19.camel@station15.dorsal.polymtl.ca> In-Reply-To: <1367868074.5194.19.camel@station15.dorsal.polymtl.ca> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2013-05/txt/msg00031.txt.bz2 Content-length: 1745 Hello, Suchakra, On 05/07/2013 03:21 AM, Suchakra Sharma wrote: > Hi, > > We tried to find out how to use the debugging agent library here [1] but > were unsuccessful. As of now, we have built a test app linked to dagent It would be nice if you post some details about how you use dagent and the error message you got. > which creates a socket file and expects commands. We wish to use it with > GDB as well as other applications to primarily objective of tracing > using GDB's fast tracepoint infra. Any help in this regard will be > appreciated. > > [1] https://github.com/MentorEmbedded/Debug-Agent-Library/wiki > I checked out the wiki and realize that the existing documentation has an assumption that readers are much familiar with GDB and GDB tracepoint. The session below shows how to install fast tracepoint through dagent. In one console, start the program in GDBserver, $ LD_PRELOAD=/install/lib/libdagent.so ./gdbserver/gdbserver :1234 ./testsuite/gdb.base/break In the other console, start GDB and connect to GDBserver, $ ./gdb ./testsuite/gdb.base/break (gdb) target remote :1234 (gdb) b main (gdb) c (gdb) b marker4 // set breakpoint to make sure program doesn't exit (gdb) ftrace *0x0804851e // set fast tracepoint at certain address (gdb) set agent on // enable agent (gdb) tstart // start tracing (gdb) c (gdb) tstop // stop tracing (gdb) tfind // examine the trace frames tracepoint collects Found trace frame 0, tracepoint 3 #0 main (argc=<unavailable>, argv=<unavailable>, envp=<unavailable>) at ../../../../git/gdb/testsuite/gdb.base/break.c:94 94 marker1 (); /* set breakpoint 11 here */ Let me know if you get something else or obviously wrong. -- Yao (é½Âå°§) ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Timer 2013-05-07 6:42 ` Timer Marc Brünink @ 2013-05-07 8:48 ` Pedro Alves 2013-05-07 10:18 ` Timer Marc Brünink 0 siblings, 1 reply; 8+ messages in thread From: Pedro Alves @ 2013-05-07 8:48 UTC (permalink / raw) To: Marc Brünink; +Cc: Doug Evans, gdb On 05/07/2013 07:42 AM, Marc Brünink wrote: > > On May 7, 2013, at 12:43 PM, Doug Evans wrote: > >> On Mon, May 6, 2013 at 2:52 AM, Marc Brünink <marc@nus.edu.sg> 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 >>> 4. Send SIGTRAP to debugged application >>> 5. continue >>> >>> Actually, now that I think about it, I should have anticipated this behaviour. >>> Is there a better way to execute a piece of code at regular intervals? You could also use another signal instead of SIGTRAP. >> bash$ man setitimer > > I suppose you are suggesting to modify either GDB or the application. This is exactly what I don't want. Any other way to accomplish this (using gdb)? You could use LD_PRELOAD to inject a library that uses setitimer into your program. I guess you could do it with gdb python scripting too. -- Pedro Alves ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Timer 2013-05-07 8:48 ` Timer Pedro Alves @ 2013-05-07 10:18 ` Marc Brünink 2013-05-07 10:51 ` Timer Pedro Alves 2013-05-07 13:44 ` Timer Tom Tromey 0 siblings, 2 replies; 8+ messages in thread From: Marc Brünink @ 2013-05-07 10:18 UTC (permalink / raw) To: Pedro Alves; +Cc: Doug Evans, gdb On May 7, 2013, at 4:48 PM, Pedro Alves wrote: > On 05/07/2013 07:42 AM, Marc Brünink wrote: >> >> On May 7, 2013, at 12:43 PM, Doug Evans wrote: >> >>> On Mon, May 6, 2013 at 2:52 AM, Marc Brünink <marc@nus.edu.sg> 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 >>>> 4. Send SIGTRAP to debugged application >>>> 5. continue >>>> >>>> Actually, now that I think about it, I should have anticipated this behaviour. >>>> Is there a better way to execute a piece of code at regular intervals? > > You could also use another signal instead of SIGTRAP. Yes, this is probably the way to go. However, I remember having some issues with different signals. Esp if an applications depends on the delivery of a signal and I use it to implement the timer interrupt. But I suppose using SIGPROF or something similar should be fine. > >>> bash$ man setitimer >> >> I suppose you are suggesting to modify either GDB or the application. This is exactly what I don't want. Any other way to accomplish this (using gdb)? > > You could use LD_PRELOAD to inject a library that uses setitimer into your program. Possible, but contradicts the gdb-only approach. > I guess you could do it with gdb python scripting too. This would be nice but does not work. As far as I remember there is a sigsupend in linux-nat.c which will thwart using a simple threading.Timer. But I might be wrong here. Whatever the reason, it does not work. Marc From gdb-return-42109-listarch-gdb=sources.redhat.com@sourceware.org Tue May 07 10:19:00 2013 Return-Path: <gdb-return-42109-listarch-gdb=sources.redhat.com@sourceware.org> Delivered-To: listarch-gdb@sources.redhat.com Received: (qmail 7725 invoked by alias); 7 May 2013 10:19:00 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb.sourceware.org> List-Subscribe: <mailto:gdb-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb/> List-Post: <mailto:gdb@sourceware.org> List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-owner@sourceware.org Delivered-To: mailing list gdb@sourceware.org Received: (qmail 7714 invoked by uid 89); 7 May 2013 10:18:59 -0000 X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,SPF_PASS,TW_NX autolearn=ham version=3.3.1 Received: from mail-da0-f43.google.com (HELO mail-da0-f43.google.com) (209.85.210.43) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 07 May 2013 10:18:58 +0000 Received: by mail-da0-f43.google.com with SMTP id u7so253039dae.30 for <gdb@sourceware.org>; Tue, 07 May 2013 03:18:57 -0700 (PDT) X-Received: by 10.66.8.69 with SMTP id p5mr1910944paa.57.1367917970512; Tue, 07 May 2013 02:12:50 -0700 (PDT) Received: from [192.168.0.104] ([112.233.222.117]) by mx.google.com with ESMTPSA id aa8sm29572136pad.14.2013.05.07.02.12.46 for <multiple recipients> (version=TLSv1 cipherìDHE-RSA-RC4-SHA bits\x128/128); Tue, 07 May 2013 02:12:48 -0700 (PDT) Message-ID: <5188C586.6010201@gmail.com> Date: Tue, 07 May 2013 10:19:00 -0000 From: xunxun <xunxun1982@gmail.com> User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: John Martin <jmartin@larraioz.com> CC: gdb@sourceware.org Subject: Re: Doubt with gdb References: <5188C0F5.2010306@larraioz.com> <5188C241.9000209@larraioz.com> <5188C2D9.2020503@gmail.com> <5188C421.3060102@larraioz.com> In-Reply-To: <5188C421.3060102@larraioz.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2013-05/txt/msg00036.txt.bz2 Content-length: 674 于 2013/5/7 星期二 17:06, John Martin 写é“: > Hello, > > And, is it possible to extract only variables of a function? > > info variables return me all variables of program. > > info variables "function" ???? > > > El 07/05/13 11:01, xunxun escribió: >> 于 2013/5/7 星期二 16:58, John Martin 写é“: >>> Hello, >>> is there any way to tell GDB that return all static variables of a >>> function? >>> best regards. >>> >>> >> |info variables | >> || >> <http://sourceware.org/gdb/current/onlinedocs/gdb/Symbols.html#index-info-variables-918> >> -- >> Best Regards, >> xunxun > Maybe you need the local variables? info local > > -- -- Best Regards, xunxun ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Timer 2013-05-07 10:18 ` Timer Marc Brünink @ 2013-05-07 10:51 ` Pedro Alves 2013-05-07 13:44 ` Timer Tom Tromey 1 sibling, 0 replies; 8+ messages in thread From: Pedro Alves @ 2013-05-07 10:51 UTC (permalink / raw) To: Marc Brünink; +Cc: Doug Evans, gdb On 05/07/2013 11:18 AM, Marc Brünink wrote: >> You could also use another signal instead of SIGTRAP. > > Yes, this is probably the way to go. However, I remember having some issues with different signals. Esp if an applications depends on the delivery of a signal and I use it to implement the timer interrupt. But I suppose using SIGPROF or something similar should be fine. > >> >>>> bash$ man setitimer >>> >>> I suppose you are suggesting to modify either GDB or the application. This is exactly what I don't want. Any other way to accomplish this (using gdb)? >> >> You could use LD_PRELOAD to inject a library that uses setitimer into your program. > > Possible, but contradicts the gdb-only approach. Well, so does the "way to go" above. :-) >> I guess you could do it with gdb python scripting too. > > This would be nice but does not work. As far as I remember there is a sigsupend in linux-nat.c which will thwart using a simple threading.Timer. But I might be wrong here. Whatever the reason, it does not work. GDB's event loop supports timer events. I guess those could be hooked up to python gdb somehow. (you'd need to use "set target-async".) But that'd require changing gdb... -- Pedro Alves ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Timer 2013-05-07 10:18 ` Timer Marc Brünink 2013-05-07 10:51 ` Timer Pedro Alves @ 2013-05-07 13:44 ` Tom Tromey 1 sibling, 0 replies; 8+ messages in thread From: Tom Tromey @ 2013-05-07 13:44 UTC (permalink / raw) To: Marc Brünink; +Cc: Pedro Alves, Doug Evans, gdb >>>>> "Marc" == Marc Brünink <marc@nus.edu.sg> writes: Pedro> I guess you could do it with gdb python scripting too. Marc> This would be nice but does not work. As far as I remember there is a Marc> sigsupend in linux-nat.c which will thwart using a simple Marc> threading.Timer. But I might be wrong here. Whatever the reason, it Marc> does not work. I would try making a new thread in Python and setting timers in this thread. Then, when a timer fires, have it use gdb.post_event to send an event to the gdb thread. This event would use gdb.execute("interrupt") to stop the inferior and trigger some processing. I'm not totally sure this will work. If not it would be interesting to know what is needed to make it work. I think at the very least it shows that inferior control isn't exposed very well to Python. Tom ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Timer 2013-05-06 9:52 Timer Marc Brünink 2013-05-07 4:43 ` Timer Doug Evans @ 2013-05-07 13:28 ` Phil Muldoon 1 sibling, 0 replies; 8+ messages in thread From: Phil Muldoon @ 2013-05-07 13:28 UTC (permalink / raw) To: Marc Brünink; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2013-05-07 13:44 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-05-06 9:52 Timer Marc Brünink 2013-05-07 4:43 ` Timer Doug Evans 2013-05-07 6:42 ` Timer Marc Brünink 2013-05-07 8:48 ` Timer Pedro Alves 2013-05-07 10:18 ` Timer Marc Brünink 2013-05-07 10:51 ` Timer Pedro Alves 2013-05-07 13:44 ` Timer Tom Tromey 2013-05-07 13:28 ` Timer Phil Muldoon
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox