Redirect GDB command output?

Redirect GDB command output?

[Paul Dubuc]

Is there any way to redirect GDB command output to a file (either
interactively or in user-defined commands)?
-- 
Paul M. Dubuc                       pdubuc@cas.org

Re: Redirect GDB command output?

[Grant Edwards]

On Wed, Oct 03, 2001 at 03:02:19PM -0400, Paul Dubuc wrote:

> Is there any way to redirect GDB command output to a file (either
> interactively or in user-defined commands)?

Nope.  People (like me) have been asking about that for a long
time, but none of have actually done anything about it.  :)

-- 
Grant Edwards
grante@visi.com

Re: Redirect GDB command output?

[Orjan Friberg]

Grant Edwards wrote:
> 
> On Wed, Oct 03, 2001 at 03:02:19PM -0400, Paul Dubuc wrote:
> 
> > Is there any way to redirect GDB command output to a file (either
> > interactively or in user-defined commands)?
> 
> Nope.  People (like me) have been asking about that for a long
> time, but none of have actually done anything about it.  :)

Maybe I'm stating the obvious here, or maybe this is not the feature you
guys were looking for, but you can use tee like this: 'gdb | tee log
2>&1', and all gdb output will be put in the file 'log' (in addition to
appearing on stdout of course).

-- 
Orjan Friberg              E-mail: orjan.friberg@axis.com
Axis Communications AB     Phone:  +46 46 272 17 68

Re: Redirect GDB command output?

[Grant Edwards]

On Fri, Oct 05, 2001 at 05:12:25PM +0200, Orjan Friberg wrote:
> Grant Edwards wrote:
> > 
> > On Wed, Oct 03, 2001 at 03:02:19PM -0400, Paul Dubuc wrote:
> > 
> > > Is there any way to redirect GDB command output to a file (either
> > > interactively or in user-defined commands)?
> > 
> > Nope.  People (like me) have been asking about that for a long
> > time, but none of have actually done anything about it.  :)
> 
> Maybe I'm stating the obvious here, or maybe this is not the
> feature you guys were looking for, but you can use tee like
> this: 'gdb | tee log 2>&1', and all gdb output will be put in
> the file 'log' (in addition to appearing on stdout of course).

The problem is that I often don't know that I want to save the
output of a command when I start gdb.  Once I've managed to
induce the failure, it's too late.  I suppose I could always
log gdb output in case I might want to save something, but that
seems like a clumsy solution.

-- 
Grant Edwards
grante@visi.com

Re: Redirect GDB command output?

[Paul Dubuc]

Orjan Friberg wrote:
> 
> Grant Edwards wrote:
> >
> > On Wed, Oct 03, 2001 at 03:02:19PM -0400, Paul Dubuc wrote:
> >
> > > Is there any way to redirect GDB command output to a file (either
> > > interactively or in user-defined commands)?
> >
> > Nope.  People (like me) have been asking about that for a long
> > time, but none of have actually done anything about it.  :)
> 
> Maybe I'm stating the obvious here, or maybe this is not the feature you
> guys were looking for, but you can use tee like this: 'gdb | tee log
> 2>&1', and all gdb output will be put in the file 'log' (in addition to
> appearing on stdout of course).

No, I was looking for something more like the redirect capability for
the
output of individual commands from the gdb prompt. Some dbx functions
our
project uses rely on this capability in dbx and (unfortunately) I see no
way of reproducing those functions with gdb user-defined commands.

We've gone through a lot of effort to migrate from Sun's C++ compiler to
the GCC's g++ in order to get past some bugs in the Sun compiler.  That
seems to have worked out well, but I've got a feeling our developers
aren't
going to like switching debuggers.

-- 
Paul M. Dubuc                       pdubuc@cas.org

Re: Redirect GDB command output?

[Tom Tromey]

>>>>> "Paul" == Paul Dubuc <pdubuc@cas.org> writes:

Paul> No, I was looking for something more like the redirect
Paul> capability for the output of individual commands from the gdb
Paul> prompt. Some dbx functions our project uses rely on this
Paul> capability in dbx and (unfortunately) I see no way of
Paul> reproducing those functions with gdb user-defined commands.

I don't think it would be very hard to write `>' (redirect) and `>>'
(redirect-append) commands for gdb.  Maybe you could even have a `|'
command that would pipe output through another process (this might be
harder due to portability constraints).

The easiest way to do this would be to have prefix commands.  For
instance `> file command' would run command with output redirected to
file.  `> file' would redirect output for all subsequence command
lines.  Plain `>' would then stop redirecting the output.

Likewise for `>>'.  Something like `|' would probably need a slightly
different syntax (for instance simply disallow a trailing gdb
command).

Using a prefix command feels a bit strange, but I implementation-wise
is probaby much, much easier.

Tom

Re: Redirect GDB command output?

[Paul Dubuc]

Tom Tromey wrote:
> 
> >>>>> "Paul" == Paul Dubuc <pdubuc@cas.org> writes:
> 
> Paul> No, I was looking for something more like the redirect
> Paul> capability for the output of individual commands from the gdb
> Paul> prompt. Some dbx functions our project uses rely on this
> Paul> capability in dbx and (unfortunately) I see no way of
> Paul> reproducing those functions with gdb user-defined commands.
> 
> I don't think it would be very hard to write `>' (redirect) and `>>'
> (redirect-append) commands for gdb.  Maybe you could even have a `|'
> command that would pipe output through another process (this might be
> harder due to portability constraints).
> 
> The easiest way to do this would be to have prefix commands.  For
> instance `> file command' would run command with output redirected to
> file.  `> file' would redirect output for all subsequence command
> lines.  Plain `>' would then stop redirecting the output.
> 
> Likewise for `>>'.  Something like `|' would probably need a slightly
> different syntax (for instance simply disallow a trailing gdb
> command).
> 
> Using a prefix command feels a bit strange, but I implementation-wise
> is probaby much, much easier.
> 
> Tom

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?

-- 
Paul M. Dubuc                       pdubuc@cas.org

Re: Redirect GDB command output?

[Andrew Cagney]

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