From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32229 invoked by alias); 6 May 2016 11:53:12 -0000 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 Received: (qmail 27744 invoked by uid 89); 6 May 2016 11:53:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.0 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=reworking X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 06 May 2016 11:53:06 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 22EFFC062C91; Fri, 6 May 2016 11:53:05 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u46Br3H7018799; Fri, 6 May 2016 07:53:04 -0400 Subject: Re: [PATCH v2 13/25] Always process target events in the main UI To: Yao Qi References: <1458573675-15478-1-git-send-email-palves@redhat.com> <1458573675-15478-14-git-send-email-palves@redhat.com> <86fuvivme3.fsf@gmail.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: Date: Fri, 06 May 2016 11:53:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <86fuvivme3.fsf@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-05/txt/msg00094.txt.bz2 On 03/22/2016 10:26 AM, Yao Qi wrote: > Pedro Alves writes: > >> This makes target events always be always processed with the main UI >> as current UI. This way, warnings, debug output, etc. are always >> consistently sent to the main console. > > Anything wrong if we don't do so? In patch 08, current_ui is switched > to right ui if something is typed in from that ui, isn't good to process > events in that ui as well? say, I type some commands in one ui, and I > expect the output go to my ui rather than the main one. The problem is that there's no connection at all between an asynchronous target event and "that" command that you mention. There may even not be a command at all. E.g., say do you do "continue&" in UI 2, and then the program spawns threads, etc. And then you type something in UI 3 (current UI is now 3), for example, switch to another inferior "run &" it. Consider that UI 4 may be the MI channel, and the frontend sends MI commands meanwhile as well, thus switching the current UI too. All the while, some random thread hits some internal event that happens to trigger some warning deep down inside symbol reading or some such. Where should the warning go? What if an internal error triggers? Where should we present the query? Or any other query, for the matter? Since it's indeterminate which is the best UI channel, best is to define it as defaulting to the main console. A similar issue happens with where e.g., "set debug infrun 1" output goes. If we don't force-default to the main UI, then output for random asynchronous events ends up going to whatever UI gdb internally happened to last switch to, which is an internal implementation detail. (Usually it'll be the last UI you typed in). Again in this case, I think we need to default to the main console/UI, and then come up with something specialized for debug output. Currently we do: if (debug_foo) fprintf_unfiltered (gdb_stdlog, ...); if (debug_bar) fprintf_unfiltered (gdb_stdlog, ...); which sends output to the current UI's gdb_stdlog. But we may want to say that "debug_foo" goes to UI 1, and "debug_bar" goes to UI 2. For example, because "set debug foo 1" was activated in UI 1, and "set debug bar" was activated in UI 2. This suggests reworking the debug APIs to have one stream object per debug setting, I think. Obviously, I'd rather not do this as requirement for this series. Thanks, Pedro Alves