From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nick Roberts Newsgroups: gmane.emacs.devel,gmane.emacs.pretest.bugs Subject: Re: various gdba bugs and requests Date: Sat, 15 Sep 2007 21:07:33 +1200 Message-ID: <18155.41173.673044.352294@kahikatea.snap.net.nz> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1189847516 5899 80.91.229.12 (15 Sep 2007 09:11:56 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 15 Sep 2007 09:11:56 +0000 (UTC) Cc: emacs-pretest-bug@gnu.org To: Tom Tromey Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 15 11:11:53 2007 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 1IWTgp-0007TP-Rv for ged-emacs-devel@m.gmane.org; Sat, 15 Sep 2007 11:11:48 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IWTgo-0001pa-Rf for ged-emacs-devel@m.gmane.org; Sat, 15 Sep 2007 05:11:46 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IWTfk-0001UX-HK for emacs-devel@gnu.org; Sat, 15 Sep 2007 05:10:40 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IWTfi-0001Tf-N4 for emacs-devel@gnu.org; Sat, 15 Sep 2007 05:10:39 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IWTfi-0001TY-76 for emacs-devel@gnu.org; Sat, 15 Sep 2007 05:10:38 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IWTfh-0005tb-PI for emacs-devel@gnu.org; Sat, 15 Sep 2007 05:10:37 -0400 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IWTfE-0003lL-So for emacs-pretest-bug@gnu.org; Sat, 15 Sep 2007 05:10:08 -0400 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1IWTfd-0005sN-Ho for emacs-pretest-bug@gnu.org; Sat, 15 Sep 2007 05:10:36 -0400 Original-Received: from viper.snap.net.nz ([202.37.101.8]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IWTfc-0005s3-Lk for emacs-pretest-bug@gnu.org; Sat, 15 Sep 2007 05:10:33 -0400 Original-Received: from kahikatea.snap.net.nz (130.41.255.123.static.snap.net.nz [123.255.41.130]) by viper.snap.net.nz (Postfix) with ESMTP id 072A23D9DD0; Sat, 15 Sep 2007 21:10:29 +1200 (NZST) Original-Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id 0E3A28FC6D; Sat, 15 Sep 2007 21:07:34 +1200 (NZST) In-Reply-To: X-Mailer: VM 7.19 under Emacs 23.0.50.9 X-Detected-Kernel: Linux 2.4-2.6 X-Detected-Kernel: Linux 2.6, seldom 2.4 (older, 4) 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:78954 gmane.emacs.pretest.bugs:19884 Archived-At: > I finally started using gdba with gdb-many-windows set to 't'. Nice > stuff! If I maximize the frame and enable the toolbar, it is as nice > as any GUI debugger I've used. > > I have run across a few minor problems though. Thanks for a comprehensive review. I am aware of most of these problems - I'm just not sure what to do about them so my replies mght be a bit disappointing. > I'm using x86 Fedora Core 6 plus the system gdb, which says: > > opsy. gdb --version > GNU gdb Red Hat Linux (6.5-15.fc6rh) > > 1. I made a new frame for gdba and maximized it. Then I moved it to > another virtual desktop. gdb ran for a long time so I switched back > to my primary desktop and worked on other things. When gdb finally > hit a breakpoint, the gud buffer appeared on one of my existing > frames. I'm not sure if is a virtual desktop or a frame problem. I don't know why the gud buffer appeared. GUD should just pop up a source buffer, generally in the window where the source was previously or the frame of the GUD buffer. > In this situation I'd prefer that this not happen -- I want gud to > remain confined to the frame on the other desktop. Perhaps there > could be a variable of some kind to control the pop-up behavior, plus > maybe a hook that is run when gdb changes state (I didn't look to see > if there is one yet, so I'm sorry if this already happens). To really understand what is happening you need to send a way to reproduce it. > 2. If I type too quickly I often see "Unexpected `starting' annotation". > This happens most often when I type "n" and then hit enter a number of > times to next through a function. This is because GDB is still running and Emacs doesn't know if the input is for GDB (in which case it should be queued) or for the program being debugged (in which case it should be sent straight away). If your program doesn't use IO you can apply the patch below. Note that Emacs should still recover after this error. > 3. At one point I restarted the inferior process using "run". gud > seemed to lose track of the inferior completely -- the stack window no > longer showed the stack; the breakpoints and locals windows did not > update. > > Exiting gud and restarting the debug session fixed this. But, that is > pretty drastic. This shouldn't happen. Please send a testcase. > 4. I'd like a way to arrange the windows differently. The standard > setup isn't to my taste. Eclipse is superior in this respect. I sometimes use gdb-many-windows but generally I just pop up extra buffers in their own frames as I need them, from the menu-bar. > 5. I found the green stop-sign icon somewhat confusing. There are two buttons that share one location on the tool bar: a red one with the word "STOP" that is visible when the inferior is running and stops execution (usually sends a SIGINT) ; and a green one with the word "GO" that is visible when execution has stopped and invokes "run" if the program has not started or has exited, or "continue" if execution has stopped in the inferior. This means if you want to restart execution in the middle of a session then you need to enter "run" in the GUD buffer. This is slightly inconvenient but I don't think it's as bad as having three separate buttons for "run", "continue" and interrupt (Ctrl-C on the command line). To see what this is like try "gdb --fullname" from the minibuffer. > 6. I often find that gdb acts strangely or sometimes crashes; one > thing that is nice about the Emacs approach to a gdb UI is that a lot > of state is kept in the gud buffer, so I can kill gdb, restart, search > backward and not lose too much. Still, it would be nice if gud > offered a way to save the state of a debug session -- say, the cwd, > the command line, and the breakpoints (plus their conditions, > commands, etc). If GDB crashes then that's a bug which should be reported to the GDB mailing list. Emacs could keep session information but how would this be more convenient than using the GDB command "set logging on"? > 7. Right now if I set a breakpoint (using C-x SPC), then edit text > earlier in that file, recompile, and re-run the inferior, the > breakpoint will be in the "wrong" location. This happens because the > breakpoint is set by file/line. > > It would be cool if gud put a marker on a breakpoint's location and > then used the marker location to move the breakpoint. Perhaps this > could be done by moving it when gdb notices that the inferior > executable has changed. Yes, I think Visual Studio DTRT but presumably it is just one program. It's difficult for Emacs to communicate such a change to GDB. > 8. I notice strange frame-raising behavior sometimes. If I set a > command on a breakpoint that ends with "cont" and then the inferior > runs for a long time, the emacs frame showing the gud buffer will > constantly raise itself. Also the gdb status on the mode line will > flicker rapidly between running and stopped. Emacs processes all output from GDB and the flicker is present because execution is repeatedly stopping and starting. Maybe I could stop the gud buffer constantly raising itself but I don't see that. Do you see it if you start with "emacs -Q"? > In GNU Emacs 22.0.990.1 (i386-koji-linux-gnu, GTK+ Version 2.10.11) I believe Fedora 7 has a backport for Emacs 22.1. -- Nick http://www.inet.net.nz/~nickrob *** gdb-ui.el 13 Sep 2007 18:01:14 +1200 1.206.2.5 --- gdb-ui.el 15 Sep 2007 20:09:26 +1200 *************** The key should be one of the cars in `gd *** 1132,1151 **** "A comint send filter for gdb. This filter may simply queue input for a later time." (when gdb-ready ! (with-current-buffer gud-comint-buffer ! (let ((inhibit-read-only t)) ! (remove-text-properties (point-min) (point-max) '(face)))) ! (if gud-running ! (progn ! (let ((item (concat string "\n"))) ! (if gdb-enable-debug (push (cons 'send item) gdb-debug-log)) ! (process-send-string proc item))) ! (if (string-match "\\\\\\'" string) ! (setq gdb-continuation (concat gdb-continuation string "\n")) ! (let ((item (concat gdb-continuation string ! (if (not comint-input-sender-no-newline) "\n")))) ! (gdb-enqueue-input item) ! (setq gdb-continuation nil)))))) ;; Note: Stuff enqueued here will be sent to the next prompt, even if it ;; is a query, or other non-top-level prompt. --- 1132,1146 ---- "A comint send filter for gdb. This filter may simply queue input for a later time." (when gdb-ready ! (with-current-buffer gud-comint-buffer ! (let ((inhibit-read-only t)) ! (remove-text-properties (point-min) (point-max) '(face)))) ! (if (string-match "\\\\\\'" string) ! (setq gdb-continuation (concat gdb-continuation string "\n")) ! (let ((item (concat gdb-continuation string ! (if (not comint-input-sender-no-newline) "\n")))) ! (gdb-enqueue-input item) ! (setq gdb-continuation nil))))) ;; Note: Stuff enqueued here will be sent to the next prompt, even if it ;; is a query, or other non-top-level prompt.