This is the mail archive of the gdb-patches@sourceware.org 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]

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


On 05/11/2012 02:41 PM, Yao Qi wrote:

> On 05/10/2012 10:00 PM, Pedro Alves wrote:


>> I'm not sure I'd call it compensating CLI uiout in MI code.  It _is_
>> a detail of MI that it supports implementing a console on top of it,
>> with "-interpreter-exec console FOO", and the ~ output.  I could claim the
>> opposite, that generic code in infrun shouldn't know about any of this
>> juggling, that it should work with whatever uiout is current.  Imagine if a
>> python uiout ever comes through (it has been discussed to add one).  Not sure
>> always flipping the current uiout to the cli uiout like that would
>> be a good idea -- seems like something that would get in the way.
> 
> My original description was not very clear.  I like this patch except
> the change in mi_on_normal_stop.  My point is, we'll print the output of
> cli commands, either in CLI or in MI.  MI can delegate console output to
> CLI with a minor decoration '~'.  Even we add a new uiout in the future,
> it can also delegate console output to CLI.


The thing is that it's not just a split of some output to the console
and other to MI.  We really have to call the functions that decide what to
print twice, once with each uiout.  That or come up with a "tee"-like uiout,
but that'd mean we'd have to buffer everything until a final flush, as otherwise
the  ~ and MI output would all be mixed up in invalid ways.

> 
> In the path using async and MI, we'll print stop event twice, one to MI
> stream (in normal_stop) and one to console (with ~ prefixed).  I suggest
> that we put code to print message to console in normal_stop, and code to
> print message to MI stream in mi_on_normal_stop.  In other words, moving
> your changes in mi_on_normal_stop to normal_stop.  In this way, the
> functionality of `printing to console' is centralized.  We may add a new
> observer print_console, and different ui_out (CLI, MI or other new
> uiout) can register their own hook method to handle `printing to
> console' differently.
> 
> My proposed approach will affect the order of MI event, and console output.


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

-- 
Pedro Alves


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