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/10/2012 10:00 PM, Pedro Alves wrote:
> I don't think the whole of normal_stop should be wrapped.  normal_stop
> itself can execute more commands through the stop hook, for example.
> We only want to print the stop event to the console, and iff, the thread
> was started by a CLI command.

I read the MI doc again today, and find you are right.

> 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.

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.

-- 
Yao (éå)


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