From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12864 invoked by alias); 11 May 2009 10:11:24 -0000 Received: (qmail 12851 invoked by uid 22791); 11 May 2009 10:11:23 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 11 May 2009 10:11:18 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id D260D2BAB2C; Mon, 11 May 2009 06:11:16 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id WF1jj7tbbjQ8; Mon, 11 May 2009 06:11:16 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id A0D752BAB1C; Mon, 11 May 2009 06:11:16 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 00D7BF5901; Mon, 11 May 2009 03:11:14 -0700 (PDT) Date: Mon, 11 May 2009 10:11:00 -0000 From: Joel Brobecker To: Eli Zaretskii Cc: gdb-patches@sourceware.org Subject: Re: Can symbol-reading produce terminal output? Message-ID: <20090511101114.GC14773@adacore.com> References: <83tz3ubd0h.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83tz3ubd0h.fsf@gnu.org> User-Agent: Mutt/1.5.18 (2008-05-17) Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-05/txt/msg00205.txt.bz2 > 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