From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2322 invoked by alias); 7 Nov 2003 16:00:25 -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 2296 invoked from network); 7 Nov 2003 16:00:24 -0000 Received: from unknown (HELO mailgw3a.lmco.com) (192.35.35.7) by sources.redhat.com with SMTP; 7 Nov 2003 16:00:24 -0000 Received: from emss04g01.ems.lmco.com ([166.17.13.122]) by mailgw3a.lmco.com (8.11.6p2/8.11.6) with ESMTP id hA7G0Lj23564; Fri, 7 Nov 2003 11:00:21 -0500 (EST) Received: from CONVERSION-DAEMON.lmco.com by lmco.com (PMDF V6.1-1X6 #30760) id <0HNZ00001OGL3E@lmco.com>; Fri, 07 Nov 2003 11:00:21 -0500 (EST) Received: from EMSS04I00.us.lmco.com ([166.17.13.135]) by lmco.com (PMDF V6.1-1X6 #30760) with ESMTP id <0HNZ00CR5OGL5I@lmco.com>; Fri, 07 Nov 2003 11:00:21 -0500 (EST) Received: from EMSS04M11.us.lmco.com ([144.219.10.27]) by EMSS04I00.us.lmco.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 07 Nov 2003 11:00:21 -0500 Date: Fri, 07 Nov 2003 16:00:00 -0000 From: "Newman, Mark (N-Superior Technical Resource Inc)" Subject: RE: filtering of commands during async operation To: Elena Zannoni Cc: gdb@sources.redhat.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 07 Nov 2003 16:00:21.0208 (UTC) FILETIME=[3F245580:01C3A548] X-SW-Source: 2003-11/txt/msg00062.txt.bz2 > 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?