This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Redirect GDB command output?



> 
> 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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]