RE: filtering of commands during async operation

Elena Zannoni
2003-11-07T17:03:48Z

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