From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Newsgroups: gmane.emacs.devel Subject: Re: gud breakage: ^done,changelist=[] Date: Fri, 29 Oct 2004 17:45:49 -0400 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: References: <87zn2ktlim.fsf@peder.flower> <16755.42540.548120.883521@farnswood.snap.net.nz> <87acukte3e.fsf@peder.flower> <16767.24485.426051.737854@farnswood.snap.net.nz> <16770.40615.484276.300510@farnswood.snap.net.nz> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1099086404 5963 80.91.229.6 (29 Oct 2004 21:46:44 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 29 Oct 2004 21:46:44 +0000 (UTC) Cc: emacs-devel@gnu.org, Jan Nieuwenhuizen , "Kim F. Storm" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 29 23:46:32 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CNeZr-0003vy-00 for ; Fri, 29 Oct 2004 23:46:32 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CNehj-0004SX-Ka for ged-emacs-devel@m.gmane.org; Fri, 29 Oct 2004 17:54:39 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CNehb-0004SP-SW for emacs-devel@gnu.org; Fri, 29 Oct 2004 17:54:31 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CNehb-0004SD-Em for emacs-devel@gnu.org; Fri, 29 Oct 2004 17:54:31 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CNehb-0004SA-CV for emacs-devel@gnu.org; Fri, 29 Oct 2004 17:54:31 -0400 Original-Received: from [206.47.199.165] (helo=simmts7-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CNeZC-0004xU-Pm; Fri, 29 Oct 2004 17:45:51 -0400 Original-Received: from empanada.home ([67.71.25.5]) by simmts7-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20041029214550.TMIK1960.simmts7-srv.bellnexxia.net@empanada.home>; Fri, 29 Oct 2004 17:45:50 -0400 Original-Received: by empanada.home (Postfix, from userid 502) id F1959343601; Fri, 29 Oct 2004 17:45:49 -0400 (EDT) Original-To: Nick Roberts In-Reply-To: <16770.40615.484276.300510@farnswood.snap.net.nz> (Nick Roberts's message of "Sat, 30 Oct 2004 08:48:55 +1300") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (darwin) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 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.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:29155 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:29155 > The general problem seems intractable because Emacs has no way of knowing if > input is going to gdb or the inferior. Yes, gdb-ui would probably need to be more complex to try and resolve the ambiguity: basically, send the text immediately (in case it's to be sent to the debugged process) but don't rule out the possibility that it was maybe sent to gdb: any code that would need to be run if the text was sent to gdb should be added to a queue of maybe-pending-code, and then carefully analyze the annotations you receive from gdb to try and infer what was sent to gdb and what was sent to the debugged process. In general it's still ambiguous anyway. > The original code (gdba.el) got round the problem by always using > a separate buffer for program input. Yes, it's a much more reliable and straightforward solution. I think the only problem with it is how to avoid popping up an input/output buffer if it's not going to be used. Maybe what we should do is to always have a separate I/O buffer but only pop-it up if the process sends output or if the user requests it via gdb-view-inferior-io. > Perhaps I should do what Stefan suggested a while ago and create a lisp > command, gdb-resync, so that the user can recover control during a debug > session and all is not lost. Yes, I think this is still necessary to work around bugs/limitations in the gdb-ui code. But it's no match to actually fixing the problems ;-) Stefan