Timer

Timer

[Marc Brünink]

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

Re: Timer

[Doug Evans]

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
?

Re: Timer

[Marc Brünink]

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 (齐尧)

Re: Timer

[Pedro Alves]

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

Re: Timer

[Marc Brünink]

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

Re: Timer

[Pedro Alves]

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

Re: Timer

[Phil Muldoon]

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

Re: Timer

[Tom Tromey]

>>>>> "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