This is the mail archive of the gdb@sourceware.cygnus.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: 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

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