This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Can symbol-reading produce terminal output?
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 11 May 2009 12:11:14 +0200
- Subject: Re: Can symbol-reading produce terminal output?
- References: <83tz3ubd0h.fsf@gnu.org>
> blockframe.c:find_pc_partial_function has this comment and code:
>
> /* Need to get the terminal in case symbol-reading produces
> output. */
> target_terminal_ours_for_output ();
> PSYMTAB_TO_SYMTAB (pst);
>
> But the other callers of PSYMTAB_TO_SYMTAB do no such thing. Which
> one is right? I volunteer to fix those that are wrong, once I know
> which ones are they.
I don't know of any rule that one should call, or not,
target_terminal_ours_for_output before we call PSYMTAB_TO_SYMTAB.
That being said, it's really odd that find_pc_partial_function has
the side-effect of potentially switching the terminal to GDB.
If we were doing things in a more systematic way, I'd say that this
call belongs in the code that handles kernel events. The terminal
should be the inferior's when we're waiting for events, and it should
be ours when we're no longer waiting (either processing an event, or
waiting for the next user command). That reminds me, though: What do
we do when we're in non-stop mode???
I couldn't get much info about this particular use of terminal_ours
from CVS (actually, I used the git mirror :-), as this predates
the CVS repo... Perhaps we could simply try removing it.
--
Joel