From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Minor gdb-ui patches to make it a bit more robust Date: Mon, 18 Feb 2008 21:42:23 -0500 Message-ID: References: <18362.728.368749.836476@kahikatea.snap.net.nz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1203388963 32460 80.91.229.12 (19 Feb 2008 02:42:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 19 Feb 2008 02:42:43 +0000 (UTC) Cc: emacs-devel@gnu.org To: Nick Roberts Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 19 03:43:07 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JRIRn-00045J-BA for ged-emacs-devel@m.gmane.org; Tue, 19 Feb 2008 03:43:07 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JRIRI-000450-OC for ged-emacs-devel@m.gmane.org; Mon, 18 Feb 2008 21:42:36 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JRIRE-00044v-VA for emacs-devel@gnu.org; Mon, 18 Feb 2008 21:42:33 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JRIRE-00044g-8l for emacs-devel@gnu.org; Mon, 18 Feb 2008 21:42:32 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JRIRE-00044d-1o for emacs-devel@gnu.org; Mon, 18 Feb 2008 21:42:32 -0500 Original-Received: from ironport2-out.pppoe.ca ([206.248.154.182]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JRIRD-0004Al-NF for emacs-devel@gnu.org; Mon, 18 Feb 2008 21:42:31 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAD7RuUfO+KMJdGdsb2JhbACQTgEwnBGBAg X-IronPort-AV: E=Sophos;i="4.25,374,1199682000"; d="scan'208";a="14686446" Original-Received: from smtp.pppoe.ca ([65.39.196.238]) by ironport2-out.pppoe.ca with ESMTP; 18 Feb 2008 21:42:30 -0500 Original-Received: from pastel.home ([206.248.163.9]) by smtp.pppoe.ca (Internet Mail Server v1.0) with ESMTP id ZEJ72230; Mon, 18 Feb 2008 21:42:30 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 588C78153; Mon, 18 Feb 2008 21:42:23 -0500 (EST) In-Reply-To: <18362.728.368749.836476@kahikatea.snap.net.nz> (Nick Roberts's message of "Tue, 19 Feb 2008 11:12:40 +1300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. 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: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:89542 Archived-At: >> Here are 2 patches which help me deal with gdb-ui. >> The first 2 hunks reset gdb-output-sink as it should after starting >> a new process. I think this is a plain bug fix, but I'll let >> Nick decide. > I don't know why you declare gdb-output-sink with a value of nil as it > has no meaning but it's harmless. This variable should really be a process property, so it makes sense for it to have an invalid value when no process is running. Setting it to an invalid default value therefore intends to help catch the case where we forget to initialize the variable. > In practice, I've not found a need to reset gdb-output-sink but you > presumably have. Indeed. I think it's pretty easy to get into such a state if you're edebugging gdba functions and abort them forcefully. > So I'm happy if you want to make these changes. Thanks. >> The second hunk make it fallback on the old gud-gdb code in case the >> prompt appears before we get to receive the expected annotations. >> I've been using M-x gdb RET with "gdb --fullname emacs" for ever and it >> took me a while to understand why it suddenly stopped working properly: >> the behavior is pretty nasty: you get all the expected GDB output but >> your input isn't sent to the gdb process (because gdb-ui thinks that >> GDB is still initializing) and completion just hangs (because it sends >> a command which isn't passed on to the process and then waits for the >> process to reply). > Using the same startup function (M-x gdb) for graphical mode and text command > mode ("fullname") has given backward compatiblity but caused a lot of grief. > Previously (Emacs 22.1) M-x gdb assumed text command mode until it received > annotations to put it in graphical mode. This led to error reports where > users wanted graphical mode and had commands in their .gdbinit which started > execution. My advice was to use M-x gdba. > In EMACS_22_BASE, I switched things round so that M-x gdb assumed graphical > mode until it received a fullname annotation to put it in text command mode. > This solved the above problem. I also removed M-x gdba and added M-x gud-gdb. Yes, I saw that. You may want to keep the gdba alias, tho. I do not disagree with this change. > More recently, Robert Marshall made a bug report about start up with > M-x gdb where he entered Gdb user commands before Emacs was ready. > On the *trunk*, I've solved this by deferring the input rather than > discarding it. I also made a couple of other related changes, one of > which was setting comint-input-sender to gdb-send earlier. I think > this change has caused the problem you are seeing. I've not made this > change on EMACS_22_BASE, so I think M-x gdb RET with "gdb --fullname > emacs" will STILL WORK there. Indeed, the specific problem I encountered is recent. > On the trunk, I want to migrate away slightly from text command mode so my > advice there is to use it via M-x gud-gdb now. I have a patch for gdb-ui.el > which will mean that M-x gdb will only work in graphical mode and doc changes > to reflect this which I propose to commit shortly. That's OK. But given the reliability problems of gdb-ui, I think it's crucial that we take a defensive-coding approach there. I.e. whenever possible check our assumptions, and not wait for someone to come up with a counter example before initializing the variables at the right place. Detecting a (gdb) prompt when we don't expect it is part of defensive coding. Maybe falling back automatically to gud-gdb is not a good idea, but detecting the situation and signalling it to the user is important. There might be all kinds of reasons why the user failed to provide the --annotate=3 argument. Also I think a good way to make it more reliable would be to make it work with several gud buffers by moving most global vars to process properties, so they're necessarily correctly initialized, and we'd be forced to think a bit harder about what's going on where. Stefan PS: Is there any hope for GDB to accept a command that puts it in annotate=3 mode, rather than having to tweak the command line for it? That would solve a lot of those problems.