FW: tracepoint frames

["Newman, Mark (N-Superior Technical Resource Inc)" <mark dot newman at lmco dot com>]

-----Original Message-----
From: Newman, Mark (N-Superior Technical Resource Inc) 
Sent: Monday, October 06, 2003 11:00 AM
To: 'Daniel Jacobowitz'
Subject: RE: tracepoint frames


Sorry reset outlook to do the reply's this way.

> -----Original Message-----
> From: Daniel Jacobowitz [mailto:drow@mvista.com]
> Sent: Monday, October 06, 2003 10:53 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: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.
> 

That is an interesting point!  This could be left up to the user.

Would that be acceptable to the community?

> 
> -- 
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer
>