From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 5C9793947425 for ; Fri, 1 Apr 2022 15:21:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5C9793947425 Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-270-4ua9sT8-MzK3joJ2FW9XlA-1; Fri, 01 Apr 2022 11:21:39 -0400 X-MC-Unique: 4ua9sT8-MzK3joJ2FW9XlA-1 Received: by mail-wm1-f70.google.com with SMTP id v62-20020a1cac41000000b0038cfe6edf3fso3029736wme.5 for ; Fri, 01 Apr 2022 08:21:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=7d2NTUnN0hCRDaeb+R4sxgVjE0RUzGWfVtUJ2W8bwKU=; b=NL+hRyXCDxKUTOCVEzXLs7ZKFaWZ3ZVIYj6e3qxc7tW8CijoMDr7AXUKB3JvlESDBj GKjkCKMrnxqhFOQuLWvXCMUKl5mY2X4dDDsfxRB3Tcq9327adHtXKAMh3I+FpAzcD7YV 9V9NHtItno1KwO+2YtIZ+bs6SkHDVA7dKbZqj7pVSPHs1LLCa/LJxWL7ct4rV+1y9Ipt BSx/ZnJp2NPSne4silPhv7SOB/A3CLVcmomHzM3tA69o6vULcH976Gva20wI7e0VRwQK oA1IWxFqxRgC+D5jCxbb2tlhQBNQ0LmJ6Ia0y4NAr6vDassqNyxLWy/8RYXpm5AE/lV+ QqUg== X-Gm-Message-State: AOAM531ljTj5wVv+6nEzLx9889qpZAmXsd37DtPG2h/JtgtsCrbMgDfX jP15yl2a1sZxukVi8kjt2keimR10G/Lc+jDS63kLlDEyeHfdlTR6H0Ho1lnXAkhYxmtLwgwhS4L RABtl8iiwRxepKYxKSnjVPw== X-Received: by 2002:a05:6000:1a43:b0:203:fc82:22d9 with SMTP id t3-20020a0560001a4300b00203fc8222d9mr8475247wry.517.1648826497633; Fri, 01 Apr 2022 08:21:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzLDJC74UhuKUCXYGjtb+lXlwuxXyeD47btFxwGJgiSCVCwOb9rseVW8gL2GX3cqjd/pliIkQ== X-Received: by 2002:a05:6000:1a43:b0:203:fc82:22d9 with SMTP id t3-20020a0560001a4300b00203fc8222d9mr8475233wry.517.1648826497454; Fri, 01 Apr 2022 08:21:37 -0700 (PDT) Received: from localhost (host86-169-131-113.range86-169.btcentralplus.com. [86.169.131.113]) by smtp.gmail.com with ESMTPSA id n62-20020a1ca441000000b0038e5e3a4e43sm138047wme.20.2022.04.01.08.21.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Apr 2022 08:21:36 -0700 (PDT) From: Andrew Burgess To: Eli Zaretskii Cc: pedro@palves.net, gdb-patches@sourceware.org, brobecker@adacore.com Subject: Re: GDB 12.0.90 available for testing In-Reply-To: <83ee2h59m2.fsf@gnu.org> 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> <83ee2i72vl.fsf@gnu.org> <87sfqx864d.fsf@redhat.com> <83fsmx59wi.fsf@gnu.org> <83ee2h59m2.fsf@gnu.org> Date: Fri, 01 Apr 2022 16:21:35 +0100 Message-ID: <87pmm096dc.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org 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: , X-List-Received-Date: Fri, 01 Apr 2022 15:21:42 -0000 Eli Zaretskii via Gdb-patches writes: >> Date: Fri, 01 Apr 2022 14:18:53 +0300 >> From: Eli Zaretskii via Gdb-patches >> Cc: brobecker@adacore.com, gdb-patches@sourceware.org, pedro@palves.net >> >> Thanks, this fixes the case of using GDB from Emacs's gdb-mi.el >> front-end. But if I invoke GDB from the shell prompt with the -i=mi >> option, it still thinks I type "g\n" no matter what I actually type at >> the prompt. >> >> So I guess there are problems with making the console input stream >> unbuffered, at least on MS-Windows? > > Or maybe read_command_file shouldn't call setbuf for the same stream > repeatedly, but only once? I think it must be the former, as far as I can tell with the patch I posted we call setbuf just once on stdin (for your -i=mi case). The read_command_file will only be called if you have gdbinit files to read in. You could try adding the -nx and -nh options when starting GDB to prevent any gdbinit files being read, but I'd be amazed if that makes a difference. Sorry I can't offer more insight. Thanks, Andrew