public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* RE: tracepoint frames
@ 2003-10-06 14:01 Newman, Mark (N-Superior Technical Resource Inc)
  2003-10-06 14:52 ` Daniel Jacobowitz
  0 siblings, 1 reply; 6+ messages in thread
From: Newman, Mark (N-Superior Technical Resource Inc) @ 2003-10-06 14:01 UTC (permalink / raw)
  To: Daniel Jacobowitz; +Cc: Jim Blandy, gdb


First - thanks for the response

-----Original Message-----
From: Daniel Jacobowitz [mailto:drow@mvista.com]
Sent: Monday, October 06, 2003 9:51 AM
To: Newman, Mark (N-Superior Technical Resource Inc)
Cc: Jim Blandy; gdb@sources.redhat.com
Subject: Re: tracepoint frames


On Mon, Oct 06, 2003 at 09:03:03AM -0400, Newman, Mark (N-Superior
Technical Resource Inc) wrote:
> 
> Jim -
> 
> When a trace point is hit some data is collected - certainly at a
> minimum the data specified by the collect statements.  However from
some
> earlier conversations and a converstaion with Ramana that additional
> information should be collected.  Michael indicated that he collected
a
> "frame" in addition to the registers, data items, etc specified in the
> collect commands.
> 
> Is it necessary to collect enough information to support say a
> "backtrace" command (after a tfind)? 

Well, it would be nice but it's not generally possible.  The backtrace
logic is pretty hairy and target-dependent; the stub has no way to find
out what will be necessary.

If this is necessary I was thinking that the sub could collect the whole
stack.  However this seems to be prohibitively expensive in both size
and speed.

> I have found that simple "print" commands will work and that "printf"
> commands will not work unless one sets up the complete environment. Is
> there a requirement or a preference on the part of the community as to
> what needs to be available when analyzing a tracepoint?

Probably if any additional data ought to be collected that shoud be
implemented in the GDB client, not silently by the stub.

I thought that the data was collected only in the stub when a tracepoint
is hit.  GDB never sees the data until a "g" or an "m" protocol message
arrives at the stub.

> 
>                                                    Mark
> 
>                                              
> -----Original Message-----
> From: Jim Blandy [mailto:jimb@redhat.com]
> Sent: Friday, October 03, 2003 7:57 PM
> To: Newman, Mark (N-Superior Technical Resource Inc)
> Cc: gdb@sources.redhat.com
> Subject: Re: tracepoint frames
> 
> 
> 
> "Newman, Mark (N-Superior Technical Resource Inc)"
> <mark.newman@lmco.com> writes:
> > The question has come up as to what needs to be collected when a
> > tracepoint is hit.  I understand that a "frame" needs to be
> > collected.  Can someone tell me what a "frame" is.  Is it a stack
> > frame, a trace frame, or what?
> 
> Well, we do have trace frames; a trace frame is the clump of
> information collected for a single tracepoint hit.  It includes
> registers, and assorted regions of memory.
> 
> You can also ask a trace frame to collect things like local variables,
> arguments, or registers.  But all that gets parsed by the code in
> tracepoint.c and turned into a 'struct collection_list', that's just a
> set of registers, memory regions, and agent expressions to collect;
> it's all parsed for you.  So at that level, there are no frames any
> more --- everything is explicit
> 
> But I don't feel like I've answered the question.  In what context did
> it come up?
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: tracepoint frames
  2003-10-06 14:01 tracepoint frames Newman, Mark (N-Superior Technical Resource Inc)
@ 2003-10-06 14:52 ` Daniel Jacobowitz
  0 siblings, 0 replies; 6+ messages in thread
From: Daniel Jacobowitz @ 2003-10-06 14:52 UTC (permalink / raw)
  To: Newman, Mark (N-Superior Technical Resource Inc); +Cc: Jim Blandy, gdb

On Mon, Oct 06, 2003 at 09:59:46AM -0400, Newman, Mark (N-Superior Technical Resource Inc) wrote:
> 
> First - thanks for the response

I don't suppose you could use a mail client which quotes normally? 
It's hard to see your responses.

> -----Original Message-----
> From: Daniel Jacobowitz [mailto:drow@mvista.com]
> Sent: Monday, October 06, 2003 9:51 AM
> To: Newman, Mark (N-Superior Technical Resource Inc)
> Cc: Jim Blandy; gdb@sources.redhat.com
> Subject: Re: tracepoint frames
> 
> 
> On Mon, Oct 06, 2003 at 09:03:03AM -0400, Newman, Mark (N-Superior
> Technical Resource Inc) wrote:
> > 
> > Jim -
> > 
> > When a trace point is hit some data is collected - certainly at a
> > minimum the data specified by the collect statements.  However from
> some
> > earlier conversations and a converstaion with Ramana that additional
> > information should be collected.  Michael indicated that he collected
> a
> > "frame" in addition to the registers, data items, etc specified in the
> > collect commands.
> > 
> > Is it necessary to collect enough information to support say a
> > "backtrace" command (after a tfind)? 
> 
> Well, it would be nice but it's not generally possible.  The backtrace
> logic is pretty hairy and target-dependent; the stub has no way to find
> out what will be necessary.



> If this is necessary I was thinking that the sub could collect the whole
> stack.  However this seems to be prohibitively expensive in both size
> and speed.

Yes, it is.  On some architectures it's not even enough.

> > I have found that simple "print" commands will work and that "printf"
> > commands will not work unless one sets up the complete environment. Is
> > there a requirement or a preference on the part of the community as to
> > what needs to be available when analyzing a tracepoint?
> 
> Probably if any additional data ought to be collected that shoud be
> implemented in the GDB client, not silently by the stub.
> 
> I thought that the data was collected only in the stub when a tracepoint
> is hit.  GDB never sees the data until a "g" or an "m" protocol message
> arrives at the stub.

Right, but GDB could request more information from the stub when it
creates the tracepoint.  The stub shouldn't have to collect anything at
all that GDB didn't tell it to.


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: tracepoint frames
  2003-10-06 13:03 Newman, Mark (N-Superior Technical Resource Inc)
@ 2003-10-06 13:51 ` Daniel Jacobowitz
  0 siblings, 0 replies; 6+ messages in thread
From: Daniel Jacobowitz @ 2003-10-06 13:51 UTC (permalink / raw)
  To: Newman, Mark (N-Superior Technical Resource Inc); +Cc: Jim Blandy, gdb

On Mon, Oct 06, 2003 at 09:03:03AM -0400, Newman, Mark (N-Superior Technical Resource Inc) wrote:
> 
> Jim -
> 
> When a trace point is hit some data is collected - certainly at a
> minimum the data specified by the collect statements.  However from some
> earlier conversations and a converstaion with Ramana that additional
> information should be collected.  Michael indicated that he collected a
> "frame" in addition to the registers, data items, etc specified in the
> collect commands.
> 
> Is it necessary to collect enough information to support say a
> "backtrace" command (after a tfind)? 

Well, it would be nice but it's not generally possible.  The backtrace
logic is pretty hairy and target-dependent; the stub has no way to find
out what will be necessary.

> I have found that simple "print" commands will work and that "printf"
> commands will not work unless one sets up the complete environment. Is
> there a requirement or a preference on the part of the community as to
> what needs to be available when analyzing a tracepoint?

Probably if any additional data ought to be collected that shoud be
implemented in the GDB client, not silently by the stub.

> 
>                                                    Mark
> 
>                                              
> -----Original Message-----
> From: Jim Blandy [mailto:jimb@redhat.com]
> Sent: Friday, October 03, 2003 7:57 PM
> To: Newman, Mark (N-Superior Technical Resource Inc)
> Cc: gdb@sources.redhat.com
> Subject: Re: tracepoint frames
> 
> 
> 
> "Newman, Mark (N-Superior Technical Resource Inc)"
> <mark.newman@lmco.com> writes:
> > The question has come up as to what needs to be collected when a
> > tracepoint is hit.  I understand that a "frame" needs to be
> > collected.  Can someone tell me what a "frame" is.  Is it a stack
> > frame, a trace frame, or what?
> 
> Well, we do have trace frames; a trace frame is the clump of
> information collected for a single tracepoint hit.  It includes
> registers, and assorted regions of memory.
> 
> You can also ask a trace frame to collect things like local variables,
> arguments, or registers.  But all that gets parsed by the code in
> tracepoint.c and turned into a 'struct collection_list', that's just a
> set of registers, memory regions, and agent expressions to collect;
> it's all parsed for you.  So at that level, there are no frames any
> more --- everything is explicit
> 
> But I don't feel like I've answered the question.  In what context did
> it come up?
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

^ permalink raw reply	[flat|nested] 6+ messages in thread

* RE: tracepoint frames
@ 2003-10-06 13:03 Newman, Mark (N-Superior Technical Resource Inc)
  2003-10-06 13:51 ` Daniel Jacobowitz
  0 siblings, 1 reply; 6+ messages in thread
From: Newman, Mark (N-Superior Technical Resource Inc) @ 2003-10-06 13:03 UTC (permalink / raw)
  To: Jim Blandy; +Cc: gdb


Jim -

When a trace point is hit some data is collected - certainly at a
minimum the data specified by the collect statements.  However from some
earlier conversations and a converstaion with Ramana that additional
information should be collected.  Michael indicated that he collected a
"frame" in addition to the registers, data items, etc specified in the
collect commands.

Is it necessary to collect enough information to support say a
"backtrace" command (after a tfind)? 

I have found that simple "print" commands will work and that "printf"
commands will not work unless one sets up the complete environment. Is
there a requirement or a preference on the part of the community as to
what needs to be available when analyzing a tracepoint?

                                                   Mark

                                             
-----Original Message-----
From: Jim Blandy [mailto:jimb@redhat.com]
Sent: Friday, October 03, 2003 7:57 PM
To: Newman, Mark (N-Superior Technical Resource Inc)
Cc: gdb@sources.redhat.com
Subject: Re: tracepoint frames



"Newman, Mark (N-Superior Technical Resource Inc)"
<mark.newman@lmco.com> writes:
> The question has come up as to what needs to be collected when a
> tracepoint is hit.  I understand that a "frame" needs to be
> collected.  Can someone tell me what a "frame" is.  Is it a stack
> frame, a trace frame, or what?

Well, we do have trace frames; a trace frame is the clump of
information collected for a single tracepoint hit.  It includes
registers, and assorted regions of memory.

You can also ask a trace frame to collect things like local variables,
arguments, or registers.  But all that gets parsed by the code in
tracepoint.c and turned into a 'struct collection_list', that's just a
set of registers, memory regions, and agent expressions to collect;
it's all parsed for you.  So at that level, there are no frames any
more --- everything is explicit

But I don't feel like I've answered the question.  In what context did
it come up?

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: tracepoint frames
  2003-10-03 15:56 Newman, Mark (N-Superior Technical Resource Inc)
@ 2003-10-03 23:57 ` Jim Blandy
  0 siblings, 0 replies; 6+ messages in thread
From: Jim Blandy @ 2003-10-03 23:57 UTC (permalink / raw)
  To: Newman, Mark (N-Superior Technical Resource Inc); +Cc: gdb


"Newman, Mark (N-Superior Technical Resource Inc)" <mark.newman@lmco.com> writes:
> The question has come up as to what needs to be collected when a
> tracepoint is hit.  I understand that a "frame" needs to be
> collected.  Can someone tell me what a "frame" is.  Is it a stack
> frame, a trace frame, or what?

Well, we do have trace frames; a trace frame is the clump of
information collected for a single tracepoint hit.  It includes
registers, and assorted regions of memory.

You can also ask a trace frame to collect things like local variables,
arguments, or registers.  But all that gets parsed by the code in
tracepoint.c and turned into a 'struct collection_list', that's just a
set of registers, memory regions, and agent expressions to collect;
it's all parsed for you.  So at that level, there are no frames any
more --- everything is explicit

But I don't feel like I've answered the question.  In what context did
it come up?

^ permalink raw reply	[flat|nested] 6+ messages in thread

* tracepoint frames
@ 2003-10-03 15:56 Newman, Mark (N-Superior Technical Resource Inc)
  2003-10-03 23:57 ` Jim Blandy
  0 siblings, 1 reply; 6+ messages in thread
From: Newman, Mark (N-Superior Technical Resource Inc) @ 2003-10-03 15:56 UTC (permalink / raw)
  To: gdb


The question has come up as to what needs to be collected when a tracepoint is hit.  I understand that a "frame" needs to be collected.  Can someone tell me what a "frame" is.  Is it a stack frame, a trace frame, or what?

                                                                           Mark Newman

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2003-10-06 14:52 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-10-06 14:01 tracepoint frames Newman, Mark (N-Superior Technical Resource Inc)
2003-10-06 14:52 ` Daniel Jacobowitz
  -- strict thread matches above, loose matches on Subject: below --
2003-10-06 13:03 Newman, Mark (N-Superior Technical Resource Inc)
2003-10-06 13:51 ` Daniel Jacobowitz
2003-10-03 15:56 Newman, Mark (N-Superior Technical Resource Inc)
2003-10-03 23:57 ` Jim Blandy

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).