Re: [PATCH 3/3] PR gdb/13860: don't lose '-interpreter-exec console EXECUTION_COMMAND''s output in async mode.

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:

Pedro> Hmm.  I did start out that way, but ended up moving to all done
Pedro> in MI.  But you may be right.  Or not.  This needs more thinking.
Pedro> :-/ I've realized that "finish" isn't really fixed yet by my
Pedro> patch -- for "finish", the normal_stop observer is skipped in
Pedro> normal_stop, and then finally called in
Pedro> finish_command_continuation.  The return value is printed by that
Pedro> print_return_value call, which is appended to the *stopped
Pedro> notification if the current uiout is MI.  A fix for this is
Pedro> indeed to flip the uiout to a cli-like uiout earlier, possible
Pedro> even before handle_inferior_event (and thinking some more, what
Pedro> if an error is thrown - we'd want to print it to the console if
Pedro> the command was a console command, presumably).  That'd mean that
Pedro> we'd get poor MI events for console commands (just like in sync
Pedro> mode), unless we do something about that, somehow.

The "finish" example gives me some pause.

I'd like it if we had a differentiation between the core code,
generating events, and the various layers over it, presenting the events
to other entities.

That is, right now finish_command_continuation calls print_return_value
to generate a bunch of ui-out calls; and then may call
observer_notify_normal_stop.

It seems like it would be cleaner to have an
observer_notify_normal_stop_finish, which takes the value as an argument
(it could just be an optional argument to the existing observer, I don't 
mind about the details).  Then the various observers could decide what
to do for themselves.  Then we wouldn't have to play games with the global
uiout to figure out how to route the finish value to all interested parties;
and maybe we could cut down on the amount of duplicated logic as well.

I've been thinking for a while that the Python normal-stop observer
ought to create a Python ui-out object and call at least bpstat_print to
get all the data into an object for event emission.

Currently we seem to have a mishmash where some code emits events and
other code prints things to ui-out.  At least if I understand it
correctly, which I am beginning to doubt.

Tom