This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: Difference between *_filtered and *_unfiltered
Mark Kettenis wrote:
>
> Date: Fri, 22 Oct 1999 10:06:02 +1000
> From: Andrew Cagney <ac131313@cygnus.com>
>
> Totally off topic.
>
> So I removed a few people from CC:
[Er, yes. Oops, Thanks :-)]
>
> The existing i387-tdep.c has:
>
> > puts_unfiltered (...);
>
> It should be using ``..._filtered''. Good time to tweek that as well
> :-)
>
> Could you explain what the difference between the _filtered and
> _unfiltered variants is, and under what circumstances one uses the one
> or the other? I couldn't find this information in the documentation.
Good question. Filtered output goes through a builtin pager (that q for
quit or return for more prompt seen when printing a backtrace).
Unfiltered output goes straight to the screen.
As a rule?
All normal output from GDB (display registers, backtrace) should be
filtered. A user on an 80x24 terminal doesn't want that register info
disappearing off the top of the screen. A user with a large xterminal
can use ``(gdb) set height 0''.
Output from the target and debug/trace messages generated by gdb's
internals should not be filtered. Having gdb prompt for a continue
every 24 lines as a result of a ``(gdb) set targetdebug 1'' command will
drive the user batty, such output can be captured using other mechanisms
such as ``script''.
Longer term, the problem will go away. The ..._filtered() and
..._unfiltered() are going to be eliminated. GDB will direct each
output to the applicable stream (gdb_stdout, gdb_stdlog, ...) and that
stream can then be configured to impose its own paging policy.
enjoy,
Andrew