This is the mail archive of the gdb-patches@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]
Other format: [Raw text]

RFC: "set logging"


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?).

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.

Also, fwiw, by "one-off" I mean the ability of a macro
(or maybe commands of a breakpoint/watchpoint) to temporarily
change gdb state and then restore things once finished.

 > Is this OK?  Any comments?  Docs OK?

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.

[btw, the $`mumble` syntax in my previous message, in case it wasn't clear,
is akin to $() in ksh/bash]

 > 2003-06-22  Daniel Jacobowitz  <drow@mvista.com>
 > 
 > 	* cli-out.c (struct ui_out_data): Add original_stream.
 > 	(cli_redirect): New function.
 > 	(cli_ui_out_impl): Add cli_redirect.
 > 	(cli_out_new): Initialize original_stream.
 > 	* ui-out.c (default_ui_out_impl): Add NULL for redirect member.
 > 	(uo_redirect, ui_out_redirect): New.
 > 	* ui-out.h (struct ui_out_impl): Add redirect member.
 > 	(redirect_ftype): New.
 > 	(ui_out_redirect): Add prototype.
 > 	* top.c (handle_redirections, pop_output_files): New functions.
 > 	(set_logging_help, set_logging_command, show_logging_command): New
 > 	functions.
 > 	(init_main): Create "set logging" and "show logging" commands.
 > 
 > 2003-06-22  Daniel Jacobowitz  <drow@mvista.com>
 > 
 > 	* mi-out.c (mi_ui_out_impl): Add NULL for redirect member.
 > 
 > 2003-06-22  Daniel Jacobowitz  <drow@mvista.com>
 > 
 > 	* tui-out.c (tui_ui_out_impl): Add NULL for redirect member.
 > 
 > 2003-06-22  Daniel Jacobowitz  <drow@mvista.com>
 > 
 > 	* gdb.texinfo (Logging output): New chapter.


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