From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Juan =?utf-8?Q?Jos=C3=A9_Garc=C3=ADa-Ripoll?= Newsgroups: gmane.emacs.devel Subject: Re: gdb fails to flush output (msys2) Date: Tue, 15 Mar 2022 10:58:24 +0100 Message-ID: <86h77zwn9b.fsf@csic.es> References: <86y21caikh.fsf@csic.es> <83o828k6a7.fsf@gnu.org> <867d8wa05w.fsf@csic.es> <837d8wjsur.fsf@gnu.org> <834k40js23.fsf@gnu.org> 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="1283"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (windows-nt) To: emacs-devel@gnu.org Cancel-Lock: sha1:aR0hm7doOZu0CqBqMnbN2gaQaXg= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Mar 15 10:59:33 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 1nU3xh-000AZ6-KN for ged-emacs-devel@m.gmane-mx.org; Tue, 15 Mar 2022 10:59:29 +0100 Original-Received: from localhost ([::1]:46844 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nU3xg-0005xi-3d for ged-emacs-devel@m.gmane-mx.org; Tue, 15 Mar 2022 05:59:28 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:41698) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nU3wq-0005CG-PM for emacs-devel@gnu.org; Tue, 15 Mar 2022 05:58:36 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]:53830) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nU3wp-0000K0-13 for emacs-devel@gnu.org; Tue, 15 Mar 2022 05:58:36 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1nU3wm-0009HY-7q for emacs-devel@gnu.org; Tue, 15 Mar 2022 10:58:32 +0100 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 5 X-Spam_score: 0.5 X-Spam_bar: / X-Spam_report: (0.5 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action 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:287178 Archived-At: Eli Zaretskii writes: > Can you show how that program behaves when invoked from the system > shell, not under the debugger? Also, if you invoke "M-x shell" inside > Emacs, and then run that program from the inferior shell, does it > behave correctly, or does it also hangs until you type Enter? Let me summarize all the questions in this single post. What is related to MSYS2 is the use of MSYS2's toolchains for building and debugging the software. There is nothing specific to MSYS2 other than specifying to Emacs that the debugger is c:/msys64/ucrt64/bin/gdb.exe or some other program from the toolchain I choose. Your paragraph abore is quite on spot. As I stated before, if I use M-x shell and invoke the debugger from the shell (still within Emacs) everything works just fine, so it is not a buffering issue. Also, to be more precise, within the debugger the program runs to completion, which means the output is completely unbuffered. It therefore should have been shown by Emacs' gdb already when I copied the text. Another indication that there is some problem with Emacs' GDB/GUD packages is that the output _is_ there. If I type a command right after the last shown output, gdb executes that command, and any following one, but re-displays the original output of the program again and again. It is somehow as if it had reinterpreted the program's output as a prompt. Is there a way I can debug how GUD is behaving or interfacing with gdb's output? I know some other major modes keep debugging information or intermediate buffers if requested. But I still have not found it for GUD. Best, -- Juan José García Ripoll http://juanjose.garciaripoll.com http://quinfog.hbar.es