This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 3/3] PR gdb/13860: don't lose '-interpreter-exec console EXECUTION_COMMAND''s output in async mode.
On 05/10/2012 06:35 AM, Yao Qi wrote:
> On 05/10/2012 12:55 AM, Pedro Alves wrote:
>> > + /* Otherwise, frame information has already been printed by
>> > + normal_stop. */
>> > + else if (target_can_async_p ())
>> > + {
>> > + /* However, CLI execution commands (-interpreter-exec
>> > + console "next", for example) in async mode have the
>> > + opposite issue. normal_stop has already printed frame
>> > + information to MI uiout, but nothing has printed the same
>> > + information to the CLI channel. We should print the
>> > + source line to the console when stepping or other similar
>> > + commands, iff the step was started by a console command
>> > + (but not if it was started with -exec-step or similar).
>> > + Breakpoint hits should always be mirrored to the
>> > + console. */
>> > + struct thread_info *tp = inferior_thread ();
> The comments are correct, and reflect the fact. However, I have some
> doubts here:
>
> - As you said in comments, normal_stop has already printed frame
> information to MI uiout, so we have to print the same to the CLI uiout
> in the MI code. Why can't we make messages printed to CLI uiout in
> normal_stop, and make messages printed to MI uiout in mi_on_normal_stop.
> This is more clear than your approach (printing frame information in MI
> uiout, and then spend effort to compensate CLI uiout in MI code).
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'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.
> I tried to wrap normal_stop in fetch_inferior_event, by "setting
> curreint_uiout to cli_uiout, and restore it after normal_stop", and it
> works to me (fixed the fails in the new tests added in this patch), and
> is illustrated by the patch below. It is quite hacky, and I'll polish
> it if I am on the right track.
Note this would _always_ output to the CLI, but we shouldn't if the
command that started the thread was -exec-next, for example.
> Yao (éå)
>
> diff --git INDEX:/gdb/infrun.c WORKDIR:/gdb/infrun.c
> index 607ef44..f41e1f4 100644
> --- INDEX:/gdb/infrun.c
> +++ WORKDIR:/gdb/infrun.c
> @@ -30,6 +30,7 @@
> #include "gdbcore.h"
> #include "gdbcmd.h"
> #include "cli/cli-script.h"
> +#include "cli-out.h"
> #include "target.h"
> #include "gdbthread.h"
> #include "annotate.h"
> @@ -2739,6 +2740,8 @@ wait_for_inferior (void)
> do_cleanups (old_cleanups);
> }
>
> +struct ui_out *cli_uiout;
> +
> /* Asynchronous version of wait_for_inferior. It is called by the
> event loop whenever a change of state is detected on the file
> descriptor corresponding to the target. It can be called more than
> @@ -2824,7 +2827,19 @@ fetch_inferior_event (void *client_data)
>
> /* We may not find an inferior if this was a process exit. */
> if (inf == NULL || inf->control.stop_soon == NO_STOP_QUIETLY)
> - normal_stop ();
> + {
> + struct ui_out *saved_uiout = current_uiout;
> + struct ui_file *old_stream
> + = cli_out_set_stream (cli_uiout, gdb_stdout);
> +
> + current_uiout = cli_uiout;
> +
> + normal_stop ();
> +
> + cli_out_set_stream (cli_uiout, old_stream);
> + current_uiout = saved_uiout;
> +
> + }
>
> if (target_has_execution
> && ecs->ws.kind != TARGET_WAITKIND_NO_RESUMED
--
Pedro Alves