RE: filtering of commands during async operation

[Elena Zannoni <ezannoni at redhat dot com>]

Newman, Mark (N-Superior Technical Resource Inc) writes:
 > 
 > 
 > > From: Elena Zannoni [mailto:ezannoni@redhat.com]
 > .....
 > > 
 > >  > Next a request - Could you add "tfind", "tdump", "tstart", 
 > > and "tstop"
 > >  > to the list of acceptable commands?  I know that if I am using
 > >  > tracepoints to monitor what is going on in a system I 
 > > don't want to wait
 > >  > and hope that whatever event I am monitoring for occurs.  
 > > I want to be
 > >  > able to look at the tracepoints while they are occurring.
 > >  > 
 > > 
 > > 
 > > It sounds like a sensible change, however I'd like to know a bit more
 > > about the direction you are headed. Surely such a change would be a
 > > candidate for a patch.
 > > 
 > 
 > I am not certain what you mean by where I am headed.  My near term
 > objective is to get tracepoints running in the background and to provide
 > some additions that I typically put in a debugger. 
 > 
 > I added some support for tracepoints in gdbserver.  I then tested that
 > in the foreground.  It seemed that everyone writing to the lists at the
 > time was doing that. That resulted in couple (3) of bug finds that were
 > fixed.
 > 
 > I provided a patch and a bug report (actually an enhancement - which I
 > cannot find now) that allows tracepoints to run while in async mode.  I
 > am now looking at running tracepoints in the background.  That resulted
 > in this thread.
 > 

I found some messages/patches and reread your postings. I now see what
you want to do.

 > I am headed at getting tracepoints to the point where I can start a
 > remote target running, establish tracepoints, and then go in and peek
 > and poke through those tracepoints without disturbing the remote process
 > (as Jim's and Michael's Heisenberg paper talked about).  I am trying to
 > go a step further than their paper by allowing one to inspect the
 > tracepoints while the remote is running, collecting, and hopefully not
 > being perturbed.  This is something I have done in the past with some
 > commercial debuggers and I am tired of doing and redoing it.
 > 

OK.

 > I have typically used this type of analysis on systems that incorporate
 > multiple computers - possibly multiple cpu's with multiple dsp's -
 > frequently these processors are headless.  Tracepoints or something like
 > them are used to help isolate a problem (feature) to a specific process
 > on a specific processor.  Then and if needed the more classic features
 > of a debugger are used to reduce the error. 
 > 
 > >  > Finally - would it be better to place a flag in 
 > > command_list_element and
 > >  > avoid all of the strcmp's altogether?
 > >  > 
 > > 
 > > The async interface was not really fully implemented, and the current
 > > subset of commands to be run while the inferior executes was just a
 > > proof of concept. 
 > 
 > I have been sorta following the thread between Andrew, Jim, and Elena.
 > I would very much like to get any changes that have been made to async.
 > I assume that other people would also.  If I can't then, as you
 > suggested Elena, I will simply have to duplicate the work that Apple
 > did.
 > 

Yeah, it would be nice to see what Apple did.

 > It may very well be that I am not the only person to find the problem
 > but rather the only one to report it.  The effect of the problem was to
 > let all commands go through.
 > 

Proabably you are right, sigh. Apple very likely ran into that as
well.

 > I have only a short history in this list and it is not clear to me.
 > Have the Apple changes been delivered?  Has the first of two sets of
 > changes only been delivered?  Is Jim going to make those changes that
 > Apple made available?  Are the Apple changes available in source with
 > Panther?

Apple definitely makes their sources available, somewhere on their
website, but I am not sure where. I remember that finding them was not
very straightforward.

elena