This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: filtering of commands during async operation



> 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 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.

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.

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.

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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]