From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: gdb fails to flush output (msys2) Date: Tue, 15 Mar 2022 18:53:09 +0200 Message-ID: <83h77zi2dm.fsf@gnu.org> References: <86y21caikh.fsf@csic.es> <83o828k6a7.fsf@gnu.org> <867d8wa05w.fsf@csic.es> <837d8wjsur.fsf@gnu.org> <834k40js23.fsf@gnu.org> <86h77zwn9b.fsf@csic.es> <77bec550-18e8-bcb9-0d32-b023f01eb3a4@secure.kjonigsen.net> <86y21btklc.fsf@csic.es> <86ee33l4rj.fsf@csic.es> <83lexbi8tj.fsf@gnu.org> <86v8wf9rly.fsf@csic.es> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38846"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Juan =?utf-8?Q?Jos=C3=A9_Garc=C3=ADa-Ripoll?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Mar 15 17:55:15 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nUAS1-0009qy-Q0 for ged-emacs-devel@m.gmane-mx.org; Tue, 15 Mar 2022 17:55:13 +0100 Original-Received: from localhost ([::1]:35296 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nUAS0-0001cQ-CT for ged-emacs-devel@m.gmane-mx.org; Tue, 15 Mar 2022 12:55:12 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:58650) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nUAQC-0000sI-9e for emacs-devel@gnu.org; Tue, 15 Mar 2022 12:53:20 -0400 Original-Received: from [2001:470:142:3::e] (port=42262 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 1nUAQC-0005ZJ-0t; Tue, 15 Mar 2022 12:53:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=xGFgAFNxstHPILswiPHCNlta3AK9057CGzMvgsApMZU=; b=S21sA7rtftodBFTNS5Ei 4anMbveokWz3Vs9N7tmYZhu4VMnoPUAcf8vrRuJfcs21n5dM5ZJWKtjQAdKtiI0LH/0YlrlCfhL8d 5KkX4xIB4Ezbpk3jfquKvHZooFhjHLW0Amv0Y2vXpj8L0WWOlQLKp2pbrWmgAhOHvvxWgI9OV95MI BcGHIUr5Pt3e5eE/I5YWXYvv3YujAK1b8J4QFWLukkwUfmXNoe960as1leqeSgSKYHtxw8x+WzEsx jgOeXKVlLwKrmRoyYmcQ3mLJTBxEkFL773iDE5kkQ3Dfwt1GJAh5RNuez+uRzxj+7qztEpxI2EPXn E7Kf1+Rj2N1eqg==; Original-Received: from [87.69.77.57] (port=3770 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 1nUAQB-0000PL-Fv; Tue, 15 Mar 2022 12:53:19 -0400 In-Reply-To: <86v8wf9rly.fsf@csic.es> (juanjose.garciaripoll@gmail.com) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:287198 Archived-At: > From: Juan José García-Ripoll > > Date: Tue, 15 Mar 2022 16:12:57 +0100 > > I think I have identified the problem. The code in Emacs assumes that > all process output is going to be prefixed by @. This is only the case > for truely asynchronous debugging (see > https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Stream-Records.html#GDB_002fMI-Stream-Records). > > There seems to be code in gdb-mi.el for transforming the debugging > experience into a remote one, such as gdb-inferior-io--init-proc, which > aims to redirect the subprocess to a tty, but this seems to have no > effect on Windows. > > Indeed, if once sets a tracepoint around gud-filter and > gud-gdbmi-marker-filter, the output is very different on Linux and on > Windows (see text files attached). Linux has successfully redirected the > output of the debugged subprocess, while the MSYS2 process gets the > output of the process mixed with GDB output. This GDB feature doesn't work on MS-Windows, only on Posix systems. But my problem is to understand how come my own debugging using gdb-mi.el on MS-Windows generally works regardless of this issue with separating the I/O of the debuggee. I'm being slowly drawn to the conclusion that the solution of that puzzle is in what your program that you are debugging does. E.g., do you see something similar if you debug any other console MinGW program with "M-x gdb"? > I am a bit stuck. I assume I should simply use the old gud-gdb interface. That's a possibility, yes.