Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@mvista.com>
To: Doug Evans <dje@transmeta.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: RFC: "set logging"
Date: Mon, 23 Jun 2003 00:15:00 -0000	[thread overview]
Message-ID: <20030623001514.GA16884@nevyn.them.org> (raw)
In-Reply-To: <16118.17005.496063.412462@casey.transmeta.com>

On Sun, Jun 22, 2003 at 04:57:33PM -0700, Doug Evans wrote:
> Daniel Jacobowitz writes:
>  > As discussed earlier:
>  >   set logging on [FILE]
>  >   set logging off
>  >   set logging overwrite [I changed the default to append]
>  >   set logging redirect
>  >   set logging file
>  >   show logging
>  > 
>  > I decided that one-off command logging was really a different class of thing
>  > from this patch, which is straight output logging, not really script-useful
>  > redirection.  So that's gone.
> 
> For my own education, what's the difference?
> 
> If one amends the definition of logging to include the
> tracing of commands, then I'd agree: they are different.
> Suppose you have a complex set of macros for driving a testsuite
> and you want to see who's calling what, etc.; or when something
> fails you want to know what was the last gdb command executed.
> And suppose typically these scripts are run in batch mode, on a server
> farm via cron jobs or some such.
> Tracing of gdb commands as they execute is very useful here.
> Not just the output of the commands but _the actual commands themselves_.
> 
> I gather this patch isn't that though (or did I miss something?).

That's what we called a "transcript" in the last conversation about
this, something I deliberately did not implement.  It's much more work
to get right.

> If one separates this from command output redirection for the purposes
> of doing something further with the output (akin to pipes in shell-speak),
> then I'd agree they are different.

And this is what I was calling "script-useful redirection", i.e.
formatted output.

> Any opinions on whether the tracing of the commands
> themselves, in addition to their output, would be a useful addition
> to "set logging"?
> "logging" suggests to me logging for debug/informational purposes,
> as opposed to redirection for subsequent processing.
> Adding tracing of the commands themselves seems like a useful addition
> to me.

Sure it is.  I just don't have demand for it, so I didn't do it.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


  reply	other threads:[~2003-06-23  0:15 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-22 20:53 Daniel Jacobowitz
2003-06-22 21:33 ` Andrew Cagney
2003-06-22 23:57 ` Doug Evans
2003-06-23  0:15   ` Daniel Jacobowitz [this message]
2003-06-23  4:51 ` Eli Zaretskii
2003-06-23 22:15 ` Daniel Jacobowitz
2003-06-23 23:09   ` Andrew Cagney
2003-06-24  4:10   ` Eli Zaretskii
2003-06-28 16:34   ` Daniel Jacobowitz
2003-07-02 20:53     ` Daniel Jacobowitz

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=20030623001514.GA16884@nevyn.them.org \
    --to=drow@mvista.com \
    --cc=dje@transmeta.com \
    --cc=gdb-patches@sources.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