From: Andrew Cagney <ac131313@cygnus.com>
To: Paul Dubuc <pdubuc@cas.org>
Cc: tromey@redhat.com, Orjan Friberg <orjan.friberg@axis.com>,
Grant Edwards <grante@visi.com>,
gdb@sourceware.cygnus.com
Subject: Re: Redirect GDB command output?
Date: Tue, 09 Oct 2001 21:56:00 -0000 [thread overview]
Message-ID: <3BC3D4B3.90203@cygnus.com> (raw)
In-Reply-To: <3BBDFF99.B9F3FA85@cas.org>
>
> Thanks for the suggestion, Tom.
>
> It would feel strange to do it this way. Sun's dbx implements functions
> and
> aliases as extenstions to ksh. I like this because it's familiar, but
> there
> are portability constraints with gdb, I know. Something that might work
> just
> as well is a new command 'redirect' that would just redirect all command
> output
> to a file that you specify (possibly with the option of 'tee'ing it
> there
> instead of redirecting completely) until 'redirect' is called again to
> change the destination. Would this be any easier to implement?
The underlying mechanism would be the same. GDB is ment to route all
output via the gdb_stdout object. Sending stuff to a file should, in
theory, just involve implementing new gdb_stdout and gdb_stderr objects
- ones that send stuff to both the previously created gdb_stdout /
gdb_stderr and the file (say).
The word ``theory'' should set off a small alarm bell though.
The first problem is that not everything uses gdb_stdout and gdb_stderr.
GDB could do with a code audit to flush out all remaining cases.
(Mutter something about #defining printf() to something nasty :-). I
don't think addresing this should be part of the change though - it is a
related but independant problem.
The second problem is slightly more interesting. Tying this mechanism
into GDB's pager code could prove, er, entertaining. I suspect again
though that the best approach might be to ignore the problem on the
first pass - get the tee mechanism working and then go back through and
clean up the pager.
The last problem is that it could potentially interact with a GUI or the
MI. I think all will be (mostly) well provided the tee mechanism uses
the existing gdb_stdout and gdb_stderr for console output.
For reference there are also several change request PR's open on this
that might contain additional information.
--
As for the user interface, a ``redirect'' command may be the best way to
go. As for what exactly that commands syntax is, I'm sure it will
result in a lively debate - ``set ???''; ``transacript''? That however,
is entirely separate to the implementation of the mechanism.
Andrew
prev parent reply other threads:[~2001-10-09 21:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-03 12:02 Paul Dubuc
2001-10-05 7:23 ` Grant Edwards
2001-10-05 8:12 ` Orjan Friberg
2001-10-05 8:47 ` Grant Edwards
2001-10-05 9:34 ` Paul Dubuc
2001-10-05 11:27 ` Tom Tromey
2001-10-05 11:44 ` Paul Dubuc
2001-10-09 21:56 ` Andrew Cagney [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3BC3D4B3.90203@cygnus.com \
--to=ac131313@cygnus.com \
--cc=gdb@sourceware.cygnus.com \
--cc=grante@visi.com \
--cc=orjan.friberg@axis.com \
--cc=pdubuc@cas.org \
--cc=tromey@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox