Can symbol-reading produce terminal output?

Can symbol-reading produce terminal output?

[Eli Zaretskii]

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.

TIA

Re: Can symbol-reading produce terminal output?

[Joel Brobecker]

> 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

Re: Can symbol-reading produce terminal output?

[Pedro Alves]

On Monday 11 May 2009 11:11:14, Joel Brobecker wrote:
> 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???

s/non-stop/async/.  See linux_nat_terminal_inferior, and remote_terminal_inferior.

Basically, if executing in the background, GDB stays with the terminal;
If executing in the foreground, the inferior gets the terminal.

The interesting question, is what happens with multi-process... Currently, I'm
just ignoring that problem.  If two programs want to fight for the terminal,
then if you want to debug them simultaneously, you should attach to
them anyway.

-- 
Pedro Alves