From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4837 invoked by alias); 6 Oct 2003 21:03:43 -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 4830 invoked from network); 6 Oct 2003 21:03:42 -0000 Received: from unknown (HELO zenia.home) (12.223.225.216) by sources.redhat.com with SMTP; 6 Oct 2003 21:03:42 -0000 Received: by zenia.home (Postfix, from userid 5433) id B921520766; Mon, 6 Oct 2003 16:02:31 -0500 (EST) To: "Newman, Mark (N-Superior Technical Resource Inc)" Cc: Andrew Cagney , gdb@sources.redhat.com Subject: Re: Tracepoints References: From: Jim Blandy Date: Mon, 06 Oct 2003 21:03:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-10/txt/msg00108.txt.bz2 "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. :)