This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
RE: Tracepoints
- From: "Newman, Mark (N-Superior Technical Resource Inc)" <mark dot newman at lmco dot com>
- To: Jim Blandy <jimb at redhat dot com>
- Cc: Andrew Cagney <ac131313 at redhat dot com>, gdb at sources dot redhat dot com
- Date: Tue, 07 Oct 2003 09:00:28 -0400
- Subject: RE: Tracepoints
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. :)
>