Overriding uiout

Overriding uiout

[Daniel Jacobowitz]

There are currently only four code paths in the entire GDB source tree where
uiout could theoretically be overridden to something other than the normal
uiout.  They're all for libgdb: gdb_value_struct_elt, gdb_thread_select,
gdb_list_thread_ids, and gdb_breakpoint_query.  The only place it actually
appears to be overridden is in gdb_value_struct_elt, which is occasionally
called from varobj code with uiout==NULL.  Otherwise it is always overridden
to itself.

This overriding mechanism makes it a bit awkward to redirect GDB's output;
any change to uiout is lost after the current command if we are running from
the prompt (although, surprisingly and IMO inconsistently, it lasts until
the end of a user-defined function).

So I'll ask again - what is this interface supposed to accomplish?  If it's
just a step down the road to passing explicit state everywhere, then I think
it's a significant step backwards in other ways, and that we should instead
let clients or wrapper functions manipulate the global state until we're
truly ready to pass a global state around - a global state which can be
overridden for this sort of task.

This is purely a design question, not an implementation objection.  For
implementation I'm restricting this feature to CLI only, and implementing it
within cli-out.  It turned out to be more elegant than I expected.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Overriding uiout

[Andrew Cagney]

> There are currently only four code paths in the entire GDB source tree where
> uiout could theoretically be overridden to something other than the normal
> uiout.  They're all for libgdb: gdb_value_struct_elt, gdb_thread_select,
> gdb_list_thread_ids, and gdb_breakpoint_query.  The only place it actually
> appears to be overridden is in gdb_value_struct_elt, which is occasionally
> called from varobj code with uiout==NULL.  Otherwise it is always overridden
> to itself.

The -interpreter-exec command needs it.  See:
http://sources.redhat.com/ml/gdb/2002-05/msg00177.html

> This overriding mechanism makes it a bit awkward to redirect GDB's output;
> any change to uiout is lost after the current command if we are running from
> the prompt (although, surprisingly and IMO inconsistently, it lasts until
> the end of a user-defined function).

That is likely something that -interpreter-exec is going to have to 
flush out.

> So I'll ask again - what is this interface supposed to accomplish?  If it's
> just a step down the road to passing explicit state everywhere, then I think
> it's a significant step backwards in other ways, and that we should instead
> let clients or wrapper functions manipulate the global state until we're
> truly ready to pass a global state around - a global state which can be
> overridden for this sort of task.

It's a step down the road of passing explict I/O re-direction.  It will 
likely be finished when GDB starts passing more global state around.

As I mentioned in another e-mail you need to ensure that the assertion:

	global uiout->stream == global gdb_stdout et.al.

holds.  There are a number of ways of doing this short term.  Replacing 
gdb_stdout with a function is one, blatting the global is another.

> This is purely a design question, not an implementation objection.  For
> implementation I'm restricting this feature to CLI only, and implementing it
> within cli-out.  It turned out to be more elegant than I expected.

Andrew