RE: Tracepoints

["Newman, Mark (N-Superior Technical Resource Inc)" <mark.newman@lmco.com>]

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)" 
> <mark.newman@lmco.com> 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.  :)
>