From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18682 invoked by alias); 7 Oct 2003 13:00:33 -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 18675 invoked from network); 7 Oct 2003 13:00:32 -0000 Received: from unknown (HELO mailgw3a.lmco.com) (192.35.35.7) by sources.redhat.com with SMTP; 7 Oct 2003 13:00:32 -0000 Received: from emss04g01.ems.lmco.com ([166.17.13.122]) by mailgw3a.lmco.com (8.11.6p2/8.11.6) with ESMTP id h97D0Ve22243; Tue, 7 Oct 2003 09:00:31 -0400 (EDT) Received: from CONVERSION-DAEMON.lmco.com by lmco.com (PMDF V6.1-1X6 #30760) id <0HME00B011GVES@lmco.com>; Tue, 07 Oct 2003 09:00:31 -0400 (EDT) Received: from EMSS04I00.us.lmco.com ([166.17.13.135]) by lmco.com (PMDF V6.1-1X6 #30760) with ESMTP id <0HME00GSC1GV6I@lmco.com>; Tue, 07 Oct 2003 09:00:31 -0400 (EDT) Received: from EMSS04M11.us.lmco.com ([144.219.10.27]) by EMSS04I00.us.lmco.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 07 Oct 2003 09:00:31 -0400 Date: Tue, 07 Oct 2003 13:00:00 -0000 From: "Newman, Mark (N-Superior Technical Resource Inc)" Subject: RE: Tracepoints To: Jim Blandy Cc: Andrew Cagney , gdb@sources.redhat.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 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 Oct 2003 13:00:31.0117 (UTC) FILETIME=[FCF0DBD0:01C38CD2] X-SW-Source: 2003-10/txt/msg00118.txt.bz2 Jim - This is fascinating. I am going over the code today - you were right - much code inspection. I did a simple test and using the --async switch am unable to get behavior to change. Is there anything else I need to know? Mark > -----Original Message----- > From: Jim Blandy [mailto:jimb@redhat.com] > Sent: Monday, October 06, 2003 5:03 PM > To: Newman, Mark (N-Superior Technical Resource Inc) > Cc: Andrew Cagney; gdb@sources.redhat.com > Subject: Re: Tracepoints > > > > "Newman, Mark (N-Superior Technical Resource Inc)" > writes: > > I don't want to go into detail until I get some kind of a > feel for how > > this will be accepted but would the community mind if I > took a stab at > > redoing the front end so that commands like "show", "tfind", "tdump" > > could be performed when the target or inferior is running? > > Oh, please take a stab at whatever you like --- the important thing is > to talk about how you plan to go about it and get some buy-in before > you go off and sink a lot of time into something. > > There's already some progress done in this area: look for references > to "asynchronous" or "async" in the code and manuals. I don't really > know what its status is, but I have the impression it's incomplete. > > > This would of course be done under either a compile switch > or a runtime > > switch to ensure compatability with the current tools. > > From gdb/doc/gdb.texinfo: > > @item -async > @cindex @code{--async} > Use the asynchronous event loop for the command-line interface. > @value{GDBN} processes all events, such as user keyboard > input, via a > special event loop. This allows @value{GDBN} to accept and > process user > commands in parallel with the debugged process being > run@footnote{@value{GDBN} built with @sc{djgpp} tools for > MS-DOS/MS-Windows supports this mode of operation, but the > event loop is > suspended when the debuggee runs.}, so you don't need to wait for > control to return to @value{GDBN} before you type the next command. > (@emph{Note:} as of version 5.1, the target side of the asynchronous > operation is not yet in place, so @samp{-async} does not work fully > yet.) > @c FIXME: when the target side of the event loop is done, > the above NOTE > @c should be removed. > > When the standard input is connected to a terminal device, > @value{GDBN} > uses the asynchronous event loop by default, unless disabled by the > @samp{-noasync} option. > > @item -noasync > @cindex @code{--noasync} > Disable the asynchronous event loop for the command-line interface. > > Not that that answers every question or anything --- just trying to > suggest starting places. > > I have this premonition that you have a lot of code reading ahead of > you. :) >