From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id F9PTME0ad199KwAAWB0awg (envelope-from ) for ; Fri, 02 Oct 2020 08:17:17 -0400 Received: by simark.ca (Postfix, from userid 112) id B98091EF44; Fri, 2 Oct 2020 08:17:17 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id E26BB1E590 for ; Fri, 2 Oct 2020 08:17:16 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 67BD0398D041; Fri, 2 Oct 2020 12:17:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 67BD0398D041 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1601641036; bh=+AMe3rRboVHFDiTWOjEEyUX52hbugznoD55cEG1nWfc=; h=Date:To:In-Reply-To:Subject:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=Ok/hfEJpLIMOJ1nI3TGQj9mAETuUshJUuKktnEVOTBGVdYhEVX5REI+DyeQCh8mNp 4S+50WCXvjCAx6cL9C8BOn1Q5YNUHxn9AO4drxyHQD3lrkY8jjOFOMri7kx4r0YSXV 8GtahQVJLwAP/K5t1MOvBBzeMghAlH2AWADjbE4s= Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 9ABAA398E406 for ; Fri, 2 Oct 2020 12:17:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9ABAA398E406 Received: from fencepost.gnu.org ([2001:470:142:3::e]:57443) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kOJzu-0004Cu-6U; Fri, 02 Oct 2020 08:17:14 -0400 Received: from [176.228.60.248] (port=2774 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kOJzt-0006JX-Ik; Fri, 02 Oct 2020 08:17:14 -0400 Date: Fri, 02 Oct 2020 15:17:06 +0300 Message-Id: <83blhkg6v1.fsf@gnu.org> To: Roy Qu In-Reply-To: (message from Roy Qu on Tue, 29 Sep 2020 07:48:18 +0800) Subject: Re: the redirected stdin/out/err for new console is wrong when the gdb's stdin/out/err is already redirected References: <83a6xam5uv.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Eli Zaretskii via Gdb-patches Reply-To: Eli Zaretskii Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" [Please use Reply All to reply, so that the list is CC'ed.] > From: Roy Qu > Date: Tue, 29 Sep 2020 07:48:18 +0800 > > Yes, (HANLDE)0 is the same as NULL. > > These code will get running when we want to run/start the inferior and at least one of inferior's > STDIN/STDOUT/STDERR is to be redirected. > si.hStdInput / si.hStdOutput/ si.hStdError are the handle for STDIN/STDOUT/STDERR you want the child > process ( console window) to use. > > Let's the following old code for the STDOUT: > > if (fd_out >= 0) > si.hStdOutput = (HANDLE) _get_osfhandle (fd_out); > else if (tty != INVALID_HANDLE_VALUE) > si.hStdOutput = tty; > else > si.hStdOutput = GetStdHandle (STD_OUTPUT_HANDLE) ; > > If the inferior process's STDOUT is to be redirected, fd_out will be a valid file_descriptor (>0) to the > redirected source, and _get_osfhandle will > get its corresponding windows handle. > If the STDOUT is not to be redirected (else if) , tty is from get_inferior_io_terminal(), which should the > inferior's current tty's handle; (I'm not sure > if here is correct, because STDIN/STDOUT/STDERR should be 3 HANDLEs， but here we use the same > one） > If the STDOUT is not to be redirected and we don't have a valid tty already (else ), then we should let the > inferior use new console STDOUT ( output to the screen). > > But here the following old code is wrong: > si.hStdOutput = GetStdHandle (STD_OUTPUT_HANDLE) ; > It tries to fetch the main gdb's currrent STDOUT handle and let the inferior to use it. If the main gdb's > STDOUT is not redirected, that's ok. > If the main gdb's STDOUT is already redirected, this will get the inferior's STDOUT redirected too, that's > wrong. > > the new code: > si.hStdOutput = NULL; > will let inferior's STDOUT use the console's default output handle (output to its console's screen). That's > what we want. > > Logic of the code for STDIN/STDERR is the same.That's ALL Thanks. My hesitation is that I don't see the significance of NULL as the standard handle documented in the MS docs of CreateProcess. What am I missing there? Another potential issue is whether, when GDB's standard output was redirected, we might want stdout of the inferior to be redirected to the same file/device. In your case, that is definitely not so, but I wonder if there are other use cases where the desired behavior could be different? Running the test suite, perhaps?