From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18799 invoked by alias); 7 Nov 2003 17:03:48 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 18710 invoked from network); 7 Nov 2003 17:03:44 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 7 Nov 2003 17:03:44 -0000 Received: by localhost.redhat.com (Postfix, from userid 469) id 599371A42DB; Fri, 7 Nov 2003 12:03:44 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16299.53360.173781.54262@localhost.redhat.com> Date: Fri, 07 Nov 2003 17:03:00 -0000 To: "Newman, Mark (N-Superior Technical Resource Inc)" Cc: Elena Zannoni , gdb@sources.redhat.com Subject: RE: filtering of commands during async operation In-Reply-To: References: X-SW-Source: 2003-11/txt/msg00067.txt.bz2 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