From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Paul Dubuc Cc: tromey@redhat.com, Orjan Friberg , Grant Edwards , gdb@sourceware.cygnus.com Subject: Re: Redirect GDB command output? Date: Tue, 09 Oct 2001 21:56:00 -0000 Message-id: <3BC3D4B3.90203@cygnus.com> References: <3BBB60BB.BB99CB3F@cas.org> <20011005092623.A1275@visi.com> <3BBDCDD9.6E281600@axis.com> <3BBDE11F.F55360ED@cas.org> <87vghuszgw.fsf@creche.redhat.com> <3BBDFF99.B9F3FA85@cas.org> X-SW-Source: 2001-10/msg00090.html > > 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