Re: tracepoints

Re: tracepoints

[Nicolas.Thery]

Edward Peschko <edwardp@excitehome.net> wrote:

> What is it with tracepoints? Are they deprecated?
>
> I got no response to my question about them about 2 weeks ago, and can't
find
> any docs about them in the gdb manual (except a small pointer that
pointed
> to nowhere)...
>
> Should these pointers be removed? I basically want to have the same
> functionality as I did in dbx (a while ago) where the program under
'trace'
> prints out all of the lines of code as they execute...
>

Hi,

I've never used tracepoints on GDB and I suspect they are not the same as
the dbx/trace feature you refer to.  But FWIW here is a pointer to some
documentation:

     http://sources.redhat.com/gdb/talks/esc-west-1999/

Hope this helps.

Nicolas



**********************************************************************
Symbian Ltd is a company registered in England and Wales with registered number 01796587 and registered office at 19 Harcourt Street, London, W1H 4HF, UK.
This message is intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify postmaster@symbian.com and delete the message and any attachments accompanying it immediately. Symbian does not accept liability for any corruption, interception, amendment, tampering or viruses occuring to this message in transit or for any message sent by its employees which is not in compliance with Symbian corporate policy.
**********************************************************************

Re: tracepoints

[Edward Peschko]

> I've never used tracepoints on GDB and I suspect they are not the same as
> the dbx/trace feature you refer to.  But FWIW here is a pointer to some
> documentation:
> 
>      http://sources.redhat.com/gdb/talks/esc-west-1999/
> 

wow.. they look a lot more powerful than I was thinking (probably could be used
to build - trivially - what I'm looking for). Why isn't there a pointer to this
article in the docs? Or for that matter, the whole doc itself? Could someone put
it there?

Ed

Re: tracepoints

[Eli Zaretskii]

> Date: Fri, 9 Mar 2001 19:01:15 -0800
> From: Edward Peschko <edwardp@excitehome.net>
> 
> Why isn't there a pointer to this article in the docs?

Because until now, I wasn't aware this article existed.  Otherwise, I'd
have converted it to Texinfo a long time ago.

> Or for that matter, the whole doc itself? Could someone put it
> there?

Until now, Someone(tm) never answered my pleas ;-)

Re: tracepoints

[Eli Zaretskii]

> From: Nicolas.Thery@Symbian.com
> Date: Fri, 9 Mar 2001 12:24:12 +0000
> 
> I've never used tracepoints on GDB and I suspect they are not the same as
> the dbx/trace feature you refer to.  But FWIW here is a pointer to some
> documentation:
> 
>      http://sources.redhat.com/gdb/talks/esc-west-1999/

Thanks a lot for this pointer!

To get tracepoints documented was on my TODO for a long time.
Unfortunately, I don't know anything about tracepoints, and the code
doesn't have enough helpful comments to allow even minimal docs to be
written.

I'm willing to convert these HTML documents into Texinfo, but I have
two issues with this:

  - Is the stuff in the above documents still valid, or were
    significant changes introduced into tracepoints since then?

  - The main document pointed to by the above URL clearly says it's a
    proprietary documentation that cannot be changed or even
    reproduced without an express _written_ consent of Cygnus.  This
    is a far cry from the GFDL, and it seems to prohibit any work done
    by anyone to produce a chapter for the GDB manual using this
    stuff.

Michael Snyder and/or Jim Blandy, could you please help resolve these
two issues?

Re: tracepoints

[Eli Zaretskii]

On Sat, 10 Mar 2001, Eli Zaretskii wrote:

> I'm willing to convert these HTML documents into Texinfo, but I have
> two issues with this:
> 
>   - Is the stuff in the above documents still valid, or were
>     significant changes introduced into tracepoints since then?
> 
>   - The main document pointed to by the above URL clearly says it's a
>     proprietary documentation that cannot be changed or even
>     reproduced without an express _written_ consent of Cygnus.  This
>     is a far cry from the GFDL, and it seems to prohibit any work done
>     by anyone to produce a chapter for the GDB manual using this
>     stuff.

And another question: does using tracepoints require the Introspect 
program mentioned in the URL above, or is it part of the official GDB 
distribution?

tracepoints

[Maxim Osipov]

Hello,

Could someone comment on status of tracepoints interface in gdb and
stubs? We plan to invest some effort to have it working in current
gdbserver and wondering, is there any active projects or existing
implementations.

Best regards,
Maxim

Re: tracepoints

[Daniel Jacobowitz]

On Mon, Jan 23, 2006 at 02:32:13PM +0300, Maxim Osipov wrote:
> Hello,
> 
> Could someone comment on status of tracepoints interface in gdb and
> stubs? We plan to invest some effort to have it working in current
> gdbserver and wondering, is there any active projects or existing
> implementations.

I do not know of any publicly available implementation of the stub
side.  A coworker of mine recently worked with a (proprietary)
simulator which implemented the existing tracepoint interface, so
I know that the GDB side of the protocol works.

Several people have implemented gdbserver support, I think.
Unfortunately, none of them were ever finished and contributed back.

-- 
Daniel Jacobowitz
CodeSourcery

Re: tracepoints

[Maxim Osipov]

Thanks a lot. Lets see what we can do here.
Maxim

On 1/23/06, Daniel Jacobowitz <drow@false.org> wrote:
> On Mon, Jan 23, 2006 at 02:32:13PM +0300, Maxim Osipov wrote:
> > Hello,
> >
> > Could someone comment on status of tracepoints interface in gdb and
> > stubs? We plan to invest some effort to have it working in current
> > gdbserver and wondering, is there any active projects or existing
> > implementations.
>
> I do not know of any publicly available implementation of the stub
> side.  A coworker of mine recently worked with a (proprietary)
> simulator which implemented the existing tracepoint interface, so
> I know that the GDB side of the protocol works.
>
> Several people have implemented gdbserver support, I think.
> Unfortunately, none of them were ever finished and contributed back.
>
> --
> Daniel Jacobowitz
> CodeSourcery
>

Re: tracepoints

[Jim Blandy]

I don't know of any publicly available stub-side implementations,
either.  I'm working on adding support for tracepoints to KGDB, the
Linux kernel stub.  When I have something ready to share I'll let the
list know.

RE: Tracepoints

[Newman, Mark (N-Superior Technical Resource Inc)]

Jim -

This is fascinating.  I am going over the code today - you were right -
much code inspection.  

I did a simple test and using the --async switch am unable to get
behavior to change.  Is there anything else I need to know?

                                              Mark

> -----Original Message-----
> From: Jim Blandy [mailto:jimb@redhat.com]
> Sent: Monday, October 06, 2003 5:03 PM
> To: Newman, Mark (N-Superior Technical Resource Inc)
> Cc: Andrew Cagney; gdb@sources.redhat.com
> Subject: Re: Tracepoints
> 
> 
> 
> "Newman, Mark (N-Superior Technical Resource Inc)" 
> <mark.newman@lmco.com> writes:
> > I don't want to go into detail until I get some kind of a 
> feel for how
> > this will be accepted but would the community mind if I 
> took a stab at
> > redoing the front end so that commands like "show", "tfind", "tdump"
> > could be performed when the target or inferior is running?
> 
> Oh, please take a stab at whatever you like --- the important thing is
> to talk about how you plan to go about it and get some buy-in before
> you go off and sink a lot of time into something.
> 
> There's already some progress done in this area: look for references
> to "asynchronous" or "async" in the code and manuals.  I don't really
> know what its status is, but I have the impression it's incomplete.
> 
> > This would of course be done under either a compile switch 
> or a runtime
> > switch to ensure compatability with the current tools.
> 
> From gdb/doc/gdb.texinfo:
> 
>   @item -async
>   @cindex @code{--async}
>   Use the asynchronous event loop for the command-line interface.
>   @value{GDBN} processes all events, such as user keyboard 
> input, via a
>   special event loop.  This allows @value{GDBN} to accept and 
> process user
>   commands in parallel with the debugged process being
>   run@footnote{@value{GDBN} built with @sc{djgpp} tools for
>   MS-DOS/MS-Windows supports this mode of operation, but the 
> event loop is
>   suspended when the debuggee runs.}, so you don't need to wait for
>   control to return to @value{GDBN} before you type the next command.
>   (@emph{Note:} as of version 5.1, the target side of the asynchronous
>   operation is not yet in place, so @samp{-async} does not work fully
>   yet.)
>   @c FIXME: when the target side of the event loop is done, 
> the above NOTE
>   @c should be removed.
> 
>   When the standard input is connected to a terminal device, 
> @value{GDBN}
>   uses the asynchronous event loop by default, unless disabled by the
>   @samp{-noasync} option.
> 
>   @item -noasync
>   @cindex @code{--noasync}
>   Disable the asynchronous event loop for the command-line interface.
> 
> Not that that answers every question or anything --- just trying to
> suggest starting places.
> 
> I have this premonition that you have a lot of code reading ahead of
> you.  :)
> 

Re: Tracepoints

[Jim Blandy]

"Newman, Mark (N-Superior Technical Resource Inc)" <mark.newman@lmco.com> writes:
> This is fascinating.  I am going over the code today - you were right -
> much code inspection.  
> 
> I did a simple test and using the --async switch am unable to get
> behavior to change.  Is there anything else I need to know?

Probably, but I don't know it either.  You may just need to start
debugging GDB and figuring out what needs to be done.

Re: Tracepoints

[Andrew Cagney]

> I did a simple test and using the --async switch am unable to get
> behavior to change.  Is there anything else I need to know?

The FIXME comments in remote.c might help here.  Any identified problems 
were recorded in that file.

Andrew

RE: Tracepoints

[Newman, Mark (N-Superior Technical Resource Inc)]

I don't want to go into detail until I get some kind of a feel for how
this will be accepted but would the community mind if I took a stab at
redoing the front end so that commands like "show", "tfind", "tdump"
could be performed when the target or inferior is running?

This would of course be done under either a compile switch or a runtime
switch to ensure compatability with the current tools.

                                     Mark Newman


-----Original Message-----
From: Andrew Cagney [mailto:ac131313@redhat.com]
Sent: Thursday, October 02, 2003 3:24 PM
To: Newman, Mark (N-Superior Technical Resource Inc)
Cc: gdb@sources.redhat.com
Subject: Re: Tracepoints


> Regarding tracepoints :
> 
> Two things
> 
> First native debugging is not impossible - it simply requires
something like 
> 
> target remote localhost:65500
> tp 52
> action
> collect i,j,k
> collect br
> end
> tstart
> cont
> 
> Second - is there any technical reason (other than the required
isolation of functionality) to stop the target to do a tfind and a
tdump.  Can these be performed while the target is running (in theory -
in practice gdb stops the target).

None ``other than the required isolation of functionality'' (read work 
on the target vector).

Andrew

Re: Tracepoints

[Jim Blandy]

"Newman, Mark (N-Superior Technical Resource Inc)" <mark.newman@lmco.com> writes:
> I don't want to go into detail until I get some kind of a feel for how
> this will be accepted but would the community mind if I took a stab at
> redoing the front end so that commands like "show", "tfind", "tdump"
> could be performed when the target or inferior is running?

Oh, please take a stab at whatever you like --- the important thing is
to talk about how you plan to go about it and get some buy-in before
you go off and sink a lot of time into something.

There's already some progress done in this area: look for references
to "asynchronous" or "async" in the code and manuals.  I don't really
know what its status is, but I have the impression it's incomplete.

> This would of course be done under either a compile switch or a runtime
> switch to ensure compatability with the current tools.

From gdb/doc/gdb.texinfo:

  @item -async
  @cindex @code{--async}
  Use the asynchronous event loop for the command-line interface.
  @value{GDBN} processes all events, such as user keyboard input, via a
  special event loop.  This allows @value{GDBN} to accept and process user
  commands in parallel with the debugged process being
  run@footnote{@value{GDBN} built with @sc{djgpp} tools for
  MS-DOS/MS-Windows supports this mode of operation, but the event loop is
  suspended when the debuggee runs.}, so you don't need to wait for
  control to return to @value{GDBN} before you type the next command.
  (@emph{Note:} as of version 5.1, the target side of the asynchronous
  operation is not yet in place, so @samp{-async} does not work fully
  yet.)
  @c FIXME: when the target side of the event loop is done, the above NOTE
  @c should be removed.

  When the standard input is connected to a terminal device, @value{GDBN}
  uses the asynchronous event loop by default, unless disabled by the
  @samp{-noasync} option.

  @item -noasync
  @cindex @code{--noasync}
  Disable the asynchronous event loop for the command-line interface.

Not that that answers every question or anything --- just trying to
suggest starting places.

I have this premonition that you have a lot of code reading ahead of
you.  :)

RE: tracepoints

[Newman, Mark (N-Superior Technical Resource Inc)]

Hi Saravan -

Lockheed does not use HP-GDB.  However in the past something very much
like tracepoints has been used as part of the integration of large
systems.  That was done at enormous cost.  I am looking at a low cost
mechanism for doing it in the future.  (I wrote the earlier
implementations and have written a current gdb/gdbserver
implementation).

I don't understand the desire to have tracepoints in a native
environment.  Tracepoints are designed to be non(read
minimally)-invasive.  They are designed to be sensitive to Heisenberg.
That means that they perturb system operation as little as possible
while collecting data. 

When we have used this type of functionality the idea was to set up a
situation, collect information, wait for some event to occur, and then
go in and look and see what happened.  That event may or may not be a
planned event.  It was used less to debug programs and more to debug
systems.  It was an integration tool (although it has been used to debug
logic problems) that allows one to see what happens in the dirty
environment of the real world.  Not in the clean environment of a test
case.

The only real differences I see between what we used in the past and
Introspect is the fact that Introspect collects data in the target
memory and the target is halted when the data is being analyzed.  The
former means to me that if I am not careful the data can have rolled off
the end of a queue before I look at it or perhaps the target locked and
I can't get at the collected data.  The latter violates the principle
espoused by Heisenberg.

Please let me know what your feelings are.  This idea has been cobbed
together by a relatively small group of people in the past.  It needs to
have the scrutiny of many talented people applied to it.

                                              Mark Newman  


-----Original Message-----
From: Saravanan [mailto:pes@india.hp.com]
Sent: Wednesday, October 01, 2003 7:34 AM
To: Newman, Mark (N-Superior Technical Resource Inc)
Cc: jimb@redhat.com; Johnson Samuel
Subject: Re: tracepoints


Hi ,
   I am Saravanan working for supporting HP-GDB/WDB product. I am doing
a feasibility
study of supporting native tracepoints in HP-GDB/WDB. 

  Does Lockheed use HP-GDB/WDB for their debugging? If yes, would it
help if we put this
feature in HP-GDB/WDB ?

Regards,
Saravanan

> 
> Saravanan
> 
> Lockheed is investing money in tracepoints.  I have not been able to
get on the GDB mailing list's to indicate our interest in supporting
them although I have spent time discussing an implementation with people
at Redhat.
> 
> If you would like to work towards a common goal please let me know
> 
>
Mark Newman

Tracepoints

[Newman, Mark (N-Superior Technical Resource Inc)]

Regarding tracepoints :

Two things

First native debugging is not impossible - it simply requires something like 

target remote localhost:65500
tp 52
action
collect i,j,k
collect br
end
tstart
cont

Second - is there any technical reason (other than the required isolation of functionality) to stop the target to do a tfind and a tdump.  Can these be performed while the target is running (in theory - in practice gdb stops the target).

                                      Mark Newman

Re: Tracepoints

[Andrew Cagney]

> Regarding tracepoints :
> 
> Two things
> 
> First native debugging is not impossible - it simply requires something like 
> 
> target remote localhost:65500
> tp 52
> action
> collect i,j,k
> collect br
> end
> tstart
> cont
> 
> Second - is there any technical reason (other than the required isolation of functionality) to stop the target to do a tfind and a tdump.  Can these be performed while the target is running (in theory - in practice gdb stops the target).

None ``other than the required isolation of functionality'' (read work 
on the target vector).

Andrew

Tracepoints

[Billalabeitia, Jose Carlos (IndSys, GEPM)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2484 bytes --]

	Hi everybody:

	First of all, my system consists of a custom PowerPC860 board, 
connected to a BDI2000 emulator, through BDM:
	
	BDI Type  : BDI2000 Rev.C
	Loader     :  V1.05
	Firmware :   V1.08 bdiGDB for MPC8xx
	Logic       :  V1.02 MPC8xx/MPC5xx

On the other hand, the BDI2000 is connected to a
Linux PC Host through the Ethernet port. In the host, I have DDD
v3.3 as the graphical debugger and gdb 5.0 as the inferior debugger.

	Up to now I can run properly all the features that DDD offers,
but tracepoints are only supported by the gdb-5.0 not by DDD in this
version, so I have to setup the tracepoints through the DDD-gdb console.
The problem comes when trying to set up the tracepoints:

(gdb)trace board.c:158	 (Here I setup a tracepoint in the code)
Tracepoint 1: file board.c line 158
(gdb)actions 1 (Here is where I should set up the variables to be recorded)
> 1
warning: '1' is not an action that I know, or is ambiguous
> 1
warning: '1' is not an action that I know, or is ambiguous
> 1
warning: '1' is not an action that I know, or is ambiguous
> 1
warning: '1' is not an action that I know, or is ambiguous
> 1
warning: '1' is not an action that I know, or is ambiguous
> 1
warning: '1' is not an action that I know, or is ambiguous
> 1
warning: '1' is not an action that I know, or is ambiguous
> 1
warning: '1' is not an action that I know, or is ambiguous
......
...... (Here I have to press ^C to quit)
^CQuit
(gdb)tstart	(Here I want to start tracing)
Target does not support this command
(gdb)tstop	(Here I want to stop tracing)
Target does not support this command
(gdb)tfind tracepoint 1	(Here I want to see the recorded values off-line)
Target does not support this command 
	

	My thinking is that this feature doesn´t depend on the 
hardware (???) but on the gdb. The gdb seems to be executing 
some instructions consecutively and in a automatic way:

	- stops the program at the tracepoint
	- records variables, registers, ... (snapshots)
	- stores them
	- continues to run the program

My questions are:

	- Is there something wrong in what I do, in the gdb console?
	- Are the tracepoints implemented in the BDI2000 gdbserver?
	- Does it depend on the BDI2000 software version?
	- Is there any other way of getting the same functionality as with
	  the tracepoints, apart from backtrace?
	- Do you know how other people work to get this functionality?
	- Is there a DDD version that supports tracepoints?

						Thank you in advance
							Billa

tracepoints

[Edward Peschko]

hey,

What is it with tracepoints? Are they deprecated? 

I got no response to my question about them about 2 weeks ago, and can't find
any docs about them in the gdb manual (except a small pointer that pointed
to nowhere)... 

Should these pointers be removed? I basically want to have the same 
functionality as I did in dbx (a while ago) where the program under 'trace' 
prints out all of the lines of code as they execute...

Ed

Re: tracepoints

[Eli Zaretskii]

> Date: Thu, 8 Mar 2001 14:29:41 -0800
> From: Edward Peschko <edwardp@excitehome.net>
> 
> What is it with tracepoints? Are they deprecated? 
> 
> I got no response to my question about them about 2 weeks ago, and can't find
> any docs about them in the gdb manual (except a small pointer that pointed
> to nowhere)... 

They exist, but are not documented, unfortunately.

> Should these pointers be removed?

No!  The pointers should be left there to nag everybody who can help
writing the missing docs, until they do.

tracepoints

[Edward Peschko]

hey,

I was wondering exactly how to use tracepoints - I'd like to be able to say

(gdb) trace

and then be able to see the exact steps that my program takes after I 
hit 'run'. dbx has this capability; I don't see why gdb shouldn't. 
I apologize if this is a FAQ or it has been asked and answered before, 
but:

    1) the answer to this question is not in the FAQ 
    2) the man page doesn't have an answer either.
    3) a search of the list archives shows that it has been *asked*
       several times, but hasn't been *answered*.

so how about it? has anybody used the facility before and is there a 
good pointer to how it is used?

Ed