From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id PKvnN7mWRWJwewAAWB0awg (envelope-from ) for ; Thu, 31 Mar 2022 07:55:37 -0400 Received: by simark.ca (Postfix, from userid 112) id D41C71F163; Thu, 31 Mar 2022 07:55:37 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,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 527061E150 for ; Thu, 31 Mar 2022 07:55:37 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id CDF8A3857C50 for ; Thu, 31 Mar 2022 11:55:36 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CDF8A3857C50 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1648727736; bh=TaHyjuhXm+Q++lAB7wACHfprnseKMjvkLCXmOQNc80c=; 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=HgcGZSM+suMcqzZSuiZ0Jk8tr1pPnyz6KGX99ZiNtHfGGcyEDZDUQObbNJbSkqS8h UinuzH/dZH/Yu/2wbByVISA/A+2j5qgy2PAV7Lfj7liE3pj7qM/Q7ctIQo2/xWX4+K 3lL+uck5Nsqmc/Wei38ZHMFIQQaaEVOAi94U+nYU= Received: from eggs.gnu.org (eggs.gnu.org [209.51.188.92]) by sourceware.org (Postfix) with ESMTPS id 4F4753857C50 for ; Thu, 31 Mar 2022 11:55:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4F4753857C50 Received: from [2001:470:142:3::e] (port=55652 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nZtOW-0000TJ-Ma; Thu, 31 Mar 2022 07:55:16 -0400 Received: from [87.69.77.57] (port=2648 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nZtOW-0001IN-46; Thu, 31 Mar 2022 07:55:16 -0400 Date: Thu, 31 Mar 2022 14:55:26 +0300 Message-Id: <83ee2i72vl.fsf@gnu.org> To: Pedro Alves In-Reply-To: <72ad3448-0ff0-f36c-d1f3-cc194c0503b8@palves.net> (message from Pedro Alves on Thu, 31 Mar 2022 10:48:18 +0100) Subject: Re: GDB 12.0.90 available for testing References: <20220320055815.2A90FA4D6C@takamaka.home> <83sfr4a93r.fsf@gnu.org> <83pmm8a7gn.fsf@gnu.org> <83o81sa6nu.fsf@gnu.org> <83ilrzap07.fsf@gnu.org> <83mth67i8m.fsf@gnu.org> <72ad3448-0ff0-f36c-d1f3-cc194c0503b8@palves.net> 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: aburgess@redhat.com, gdb-patches@sourceware.org, brobecker@adacore.com Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" > Date: Thu, 31 Mar 2022 10:48:18 +0100 > Cc: gdb-patches@sourceware.org, Andrew Burgess > From: Pedro Alves > > >> https://sourceware.org/bugzilla/show_bug.cgi?id=29002 > > > > Ping! The two issues described in this PR are IMO serious and should > > be fixed before GDB 12.1 is released. Could someone please respond to > > what I wrote there, and propose how to fix this without adversely > > affecting GNU/Linux (and possibly other non-Windows platforms)? > > So from the bugzilla discussion, it sounds like calling setvbuf all the > time is a bad idea. So we should call it once for a given stream early > on, just once. That sounds reasonable to me. However, the patch you > attached in bugzilla doesn't seem to be doing that correctly: > > > 836 if (!done_once && !ISATTY (stream)) > 837 { > 838 setbuf (stream, NULL); > 839 done_once = 1; > 840 } > 836 > 841 > > because that will only do it once for all streams, and we need to do this > once per stream. The above was what we did in GDB 11 and before. I'm okay with testing an alternative patch, or trying to write one myself, but for the latter I need some guidance, as I'm not familiar with how streams are managed in GDB. Specifically, how do I "do this once per stream"? It would require some flag for each stream (in 'struct ui') or something?