Re: Emacs 23.0.0.1 fails parsing gdb output
In my opinion we should very much make the gdb-ui code the default. As for keeping support for --fullname, I believe it's needed as long as the gdb-ui code isn't as robust as the --fullname one. I'm not sure what is the current state of affairs, but I've had to switch to --fullname because of minor problems at least once in the last year. I think another issue is multiple-debugging session support (though I like the new gdb-ui too). Not critical for most people, but may be for some. FWIW I never suggested removing --fullname now, just not allowing it's use with M-x gdb so that the Graphical Interface would work in those cases where currently only M-x gdba does. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs 23.0.0.1 fails parsing gdb output
Stefan Monnier [EMAIL PROTECTED] writes: In my opinion we should very much make the gdb-ui code the default. As for keeping support for --fullname, I believe it's needed as long as the gdb-ui code isn't as robust as the --fullname one. I'm not sure what is the current state of affairs, but I've had to switch to --fullname because of minor problems at least once in the last year. I think another issue is multiple-debugging session support (though I like the new gdb-ui too). Not critical for most people, but may be for some. -miles -- Do not taunt Happy Fun Ball. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs 23.0.0.1 fails parsing gdb output
From: Nick Roberts [EMAIL PROTECTED] Date: Sat, 14 Jul 2007 12:21:55 +1200 Cc: emacs-pretest-bug@gnu.org IMO, it's not nice to change the package semantic in such radical ways behind users' backs. I know a few people who like the current M-x gdb and will not be pleased to see the GUI version instead. It's not nice trying to get Emacs to work out which option has been selected as well as which version of GDB is running. ??? Emacs is a program; how can one be ``nice'' or ``not nice'' to a program? Are you saying it is hard to check the value of a single variable and invoke one of two functions depending on that? What am I missing here? At it's basic level, the GUI version works just like the old version except that breakpoints are marked with a bulet in the fringe. What happens if there's no fringe? What happens in a no-window (-nw) session? Also, what if in the future we decide that gdb-ui opens its additional windows by default (a reasonable decision for a GUI-oriented debugging interface)? Johan Walles is the just about the only user to make a bug report on it since the release. If users choose not to report problems, then it makes it hard to accomodate their view. I didn't say I objected to invoking gdb-ui by default. How about if we modify M-x gdb to invoke gdb-ui if a certain option is set? Whether this option should be on or off by default, is another matter, but at least users will be able to control what UI they get by flipping a single option. Most users will just use the default until it causes problems, so I don't see that there's much difference. It makes difference to those who would like the old interface: they will need to flip a single variable, and still use the same command. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs 23.0.0.1 fails parsing gdb output
Stefan Monnier [EMAIL PROTECTED] writes: + (if (case gud-gdb-annotations +(2 nil) +(nil (string-match --annotate=3 command-line)) FWIW, this should be `((nil) ...)'. `nil' means an empty KEYLIST (which always fails). The manual says To make a clause that matches the actual symbol `t', `nil', or `otherwise', enclose the symbol in a list. Maybe a similar note should be added to the docstring. -- Johan Bockgård ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs 23.0.0.1 fails parsing gdb output
On 7/14/07, Eli Zaretskii [EMAIL PROTECTED] wrote: ??? Emacs is a program; how can one be ``nice'' or ``not nice'' to a program? Are you saying it is hard to check the value of a single variable and invoke one of two functions depending on that? What am I missing here? Animism? Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs 23.0.0.1 fails parsing gdb output
IMO, it's not nice to change the package semantic in such radical ways behind users' backs. I know a few people who like the current M-x gdb and will not be pleased to see the GUI version instead. It's not nice trying to get Emacs to work out which option has been selected as well as which version of GDB is running. ??? Emacs is a program; how can one be ``nice'' or ``not nice'' to a program? Are you saying it is hard to check the value of a single variable and invoke one of two functions depending on that? What am I missing here? This is just a misunderstanding in the use of English. Here, to whom it is not nice is implicit. In your sentence it's the users. In mine, the developer(s). At it's basic level, the GUI version works just like the old version except that breakpoints are marked with a bulet in the fringe. What happens if there's no fringe? It creates a display margin and displays the bullet there. What happens in a no-window (-nw) session? It creates a display margin and displays a B/b there. Also, what if in the future we decide that gdb-ui opens its additional windows by default (a reasonable decision for a GUI-oriented debugging interface)? If users like the old behaviour then we wouldn't change the default. Johan Walles is the just about the only user to make a bug report on it since the release. If users choose not to report problems, then it makes it hard to accomodate their view. I didn't say I objected to invoking gdb-ui by default. Even if you did, I could try to convice you that it would be alright. Clearly I can't do that who have not expressed their reasons. How about if we modify M-x gdb to invoke gdb-ui if a certain option is set? Whether this option should be on or off by default, is another matter, but at least users will be able to control what UI they get by flipping a single option. Most users will just use the default until it causes problems, so I don't see that there's much difference. It makes difference to those who would like the old interface: they will need to flip a single variable, and still use the same command. You might, indeed, be right but I don't know who these people are because they haven't posted to this mailing list. My ultimate aim is to _replace_ the old mode with one using GDB/MI, which will also need changes to GDB. A release from the trunk won't happen for a long time. I think this is an opportunity to make that transition. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs 23.0.0.1 fails parsing gdb output
How about if we modify M-x gdb to invoke gdb-ui if a certain option is set? Whether this option should be on or off by default, is another matter, but at least users will be able to control what UI they get by flipping a single option. Most users will just use the default until it causes problems, so I don't see that there's much difference. In my opinion we should very much make the gdb-ui code the default. As for keeping support for --fullname, I believe it's needed as long as the gdb-ui code isn't as robust as the --fullname one. I'm not sure what is the current state of affairs, but I've had to switch to --fullname because of minor problems at least once in the last year. Of course, I didn't file a bug report about it: that would have been too easy, right? More seriously, I simply had no time at that moment and couldn't reproduce it afterwards. I'm not sure what's the reason for gdb-ui's historical instability, but I suspect it's due to the interface between gdb and gdb-ui (the --annotate-3 annotations). I hope GDB/MI is better. Unless the problem is directly in GDB's own instability. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs 23.0.0.1 fails parsing gdb output
To make a clause that matches the actual symbol `t', `nil', or `otherwise', enclose the symbol in a list. Thanks for catching it. Not that it mattered since this was intended for human consumption exclusively: don't ever pass it to `patch' or try to splice the code in by hand either. Not only it's got the above bug but it's a quickdirty hack. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs 23.0.0.1 fails parsing gdb output
2007/7/13, Nick Roberts [EMAIL PROTECTED]: I think that M-x gdb doesn't work in you start execution from within a script. In this case you must use M-x gdba. Does this work? Yes! What's the difference betweeen gdb and gdba? I wasn't able to find anything documenting the difference, according to the docs they seem to do roughly the same thing. M-x gdba assumes that GDB is being run with the --annotate=3 option. M-x gdb filters the output to determine whether GDB is being run with --fullname or --annotate=3. The former gives the old Emacs 21 functionality (or lack of it!) and is worth using if all else fails. As someone read somewhere that --annotate=3 should be used with Emacs22, that's what we're using with Emacs22. So if all gdb (sans a) does it trying to figure that out, gdba is what we should and will use. So they do indeed do the same thing, in most cases, when --annotate=3 is used (the default). There is a problem when GDB commands like run are included in GDB scripts because these get run _before_ GDB commands that Emacs uses to set up the mode. Perhaps I'll add a note in the manual. Something in there about how gdba and gdb differs would be great! Thanks a lot for your quick and insightful comments! Regards //Johan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs 23.0.0.1 fails parsing gdb output
...What's the difference betweeen gdb and gdba? I wasn't able to find anything documenting the difference, according to the docs they seem to do roughly the same thing. M-x gdba assumes that GDB is being run with the --annotate=3 option. M-x gdb filters the output to determine whether GDB is being run with --fullname or --annotate=3. The former gives the old Emacs 21 functionality (or lack of it!) and is worth using if all else fails. As someone read somewhere that --annotate=3 should be used with Emacs22, that's what we're using with Emacs22. So if all gdb (sans a) does it trying to figure that out, gdba is what we should and will use. So they do indeed do the same thing, in most cases, when --annotate=3 is used (the default). There is a problem when GDB commands like run are included in GDB scripts because these get run _before_ GDB commands that Emacs uses to set up the mode. Perhaps I'll add a note in the manual. Something in there about how gdba and gdb differs would be great! This is a suggestion to the mailing list, but also a RFA to RMS. Now that gdb-ui is part of the release, how about renaming gdb to gdbf and gdba to gdb on the trunk so that the new mode takes the focus? This would ensure that GDB initialisation scripts that start execution don't cause problems with M-x gdb. It would also mean that using -fullname would only work for M-x gdbf, for which it could be the default. WDYT? -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs 23.0.0.1 fails parsing gdb output
From: Nick Roberts [EMAIL PROTECTED] Date: Fri, 13 Jul 2007 23:26:20 +1200 Cc: emacs-pretest-bug@gnu.org This is a suggestion to the mailing list, but also a RFA to RMS. Now that gdb-ui is part of the release, how about renaming gdb to gdbf and gdba to gdb on the trunk so that the new mode takes the focus? IMO, it's not nice to change the package semantic in such radical ways behind users' backs. I know a few people who like the current M-x gdb and will not be pleased to see the GUI version instead. How about if we modify M-x gdb to invoke gdb-ui if a certain option is set? Whether this option should be on or off by default, is another matter, but at least users will be able to control what UI they get by flipping a single option. This would ensure that GDB initialisation scripts that start execution don't cause problems with M-x gdb. It would also mean that using -fullname would only work for M-x gdbf, for which it could be the default. Can't we fix these issues with N-x gdb, so that both UIs work with them? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs 23.0.0.1 fails parsing gdb output
How about if we modify M-x gdb to invoke gdb-ui if a certain option is set? Whether this option should be on or off by default, is another matter, but at least users will be able to control what UI they get by flipping a single option. Yes, I suggest the following: - introduce a new custom var with three values (one for --fullname, one for --annotate=3 and one for auto-detect, this last one being the default). - get rid of the `gdba' name. - improve `gdb's autodetection by checking the command provided for --fullname or --annotate=3 (this may fail if the command just runs a script, so we still need the current autodetection). - change default gud-gdb-command-name depending on gud-gdb-annotations. See below a sample patch (very much *not intended for use as is*) that hopefully makes my suggestion more clear. Stefan --- orig/lisp/progmodes/gud.el +++ mod/lisp/progmodes/gud.el @@ -592,7 +592,15 @@ ;; History of argument lists passed to gdb. (defvar gud-gdb-history nil) -(defcustom gud-gdb-command-name gdb --annotate=3 +(defcustom gud-gdb-annotations nil + Level of sophistication of interfacing with GDB. + :type '(choice (const :tag Auto-detect nil) + (const :tag Old style 2) + (const :tag Modern 3))) + +(defcustom gud-gdb-command-name + (concat gdb + (if (eq gud-gdb-annotations 2) --fullname --annotate=3)) Default command to execute an executable under the GDB debugger. :type 'string :group 'gud) @@ -728,6 +736,12 @@ session. (interactive (list (gud-query-cmdline 'gdb))) + (if (case gud-gdb-annotations +(2 nil) +(nil (string-match --annotate=3 command-line)) +(t t)) + (gdba command-line) + (when (and gud-comint-buffer (buffer-name gud-comint-buffer) (get-buffer-process gud-comint-buffer) @@ -770,7 +784,7 @@ (setq paragraph-start comint-prompt-regexp) (setq gdb-first-prompt t) (setq gud-filter-pending-text nil) - (run-hooks 'gdb-mode-hook)) + (run-hooks 'gdb-mode-hook))) ;; One of the nice features of GDB is its impressive support for ;; context-sensitive command completion. We preserve that feature ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs 23.0.0.1 fails parsing gdb output
IMO, it's not nice to change the package semantic in such radical ways behind users' backs. I know a few people who like the current M-x gdb and will not be pleased to see the GUI version instead. I agree. How about if we modify M-x gdb to invoke gdb-ui if a certain option is set? That would be ok. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs 23.0.0.1 fails parsing gdb output
This is a suggestion to the mailing list, but also a RFA to RMS. Now that gdb-ui is part of the release, how about renaming gdb to gdbf and gdba to gdb on the trunk so that the new mode takes the focus? IMO, it's not nice to change the package semantic in such radical ways behind users' backs. I know a few people who like the current M-x gdb and will not be pleased to see the GUI version instead. It's not nice trying to get Emacs to work out which option has been selected as well as which version of GDB is running. At it's basic level, the GUI version works just like the old version except that breakpoints are marked with a bulet in the fringe. So I'd like to know why some people would not be pleased to see the GUI version instead. Johan Walles is the just about the only user to make a bug report on it since the release. If users choose not to report problems, then it makes it hard to accomodate their view. How about if we modify M-x gdb to invoke gdb-ui if a certain option is set? Whether this option should be on or off by default, is another matter, but at least users will be able to control what UI they get by flipping a single option. Most users will just use the default until it causes problems, so I don't see that there's much difference. This would ensure that GDB initialisation scripts that start execution don't cause problems with M-x gdb. It would also mean that using -fullname would only work for M-x gdbf, for which it could be the default. Can't we fix these issues with N-x gdb, so that both UIs work with them? Not without making changes to the behaviour of annotations in GDB itself which I don't intend to do as we're trying to move over to GDB/MI. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs 23.0.0.1 fails parsing gdb output
Stefan Monnier writes: How about if we modify M-x gdb to invoke gdb-ui if a certain option is set? Whether this option should be on or off by default, is another matter, but at least users will be able to control what UI they get by flipping a single option. Yes, I suggest the following: - introduce a new custom var with three values (one for --fullname, one for --annotate=3 and one for auto-detect, this last one being the default). - get rid of the `gdba' name. - improve `gdb's autodetection by checking the command provided for --fullname or --annotate=3 (this may fail if the command just runs a script, so we still need the current autodetection). - change default gud-gdb-command-name depending on gud-gdb-annotations. This seems to be the classic Emacs approach of an option for everything. Sometimes I prefer that someone who has a deeper understanding to make clear choices for me. In the case of M-x gdb I'm striving towards having just one mode. AFAICS the old mode still remains because the new one doesn't do everything that the old one does. However, that doesn't mean that we should encourage or legitimise use of the old one. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs 23.0.0.1 fails parsing gdb output
IMO, it's not nice to change the package semantic in such radical ways behind users' backs. I know a few people who like the current M-x gdb and will not be pleased to see the GUI version instead. I agree. Perhaps being disruptive sometimes is a good thing. How about if we modify M-x gdb to invoke gdb-ui if a certain option is set? That would be ok. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs 23.0.0.1 fails parsing gdb output
In GNU Emacs 23.0.0.1 (i486-pc-linux-gnu, GTK+ Version 2.10.11) of 2007-07-06 on helios I have GNU gdb 6.6-debian and it works fine with GNU Emacs 23.0.0.3 (i686-pc-linux-gnu, GTK+ Version 2.10.11). Does it fail with Emacs 22.1? I'm having the same or very similar problems on Solaris / Sparc using Emacs 22.1 and gdb-6.5. There might be problems with GDB on Solaris / Sparc. then post the value of gdb-debug-log to [EMAIL PROTECTED] Attached. This log looks OK but it's prior to execution. Your earlier report, which I should have looked at more carefully, shows the problem occurs after execution begins: Loading GDB sequences... *** Hope you've got /home/appeal/bin or //depot/jrockit/cce/gdbutils in your path *** I use a few helper scripts nowadays Generating isNativeIp and printmodule What happens if you start your application under GDB without the GDB scripts? I think that M-x gdb doesn't work in you start execution from within a script. In this case you must use M-x gdba. Does this work? Since this (or something very similar) is a problem with both 22.1 and 23.0.0.1 I'm posting to both bug lists. Yes, it's taken so long to release 22.1, I forget that bug-gnu-emacs is the proper mailing list for 22.1. It's probably sufficient though to keep the thread on emacs-pretest-bug and just report conclusions (if any) on bug-gnu-emacs. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs 23.0.0.1 fails parsing gdb output
I'm attaching a new debug log where I've gone one step further and done f in the GDB pane to get the source window to refresh. That did get me a bunch of error messages which might make this log a bit more interesting to you. It still doesn't seem to contain the errors but I don't think they can be avoided without deffering execution or using M-x gdba anyway. What happens if you start your application under GDB without the GDB scripts? The reason we have the scripts is that what we're debugging is a library (libjvm.so), and the scripts run load and run things long enough for us to get into our library. If we don't run the scripts, nothing will even get loaded into gdb. I see, but presumably you can do this after M-x gdb has started up: M-x gdb Run gdb (like this): gdb -annotate=3 myprog In GUD buffer: Current directory is /home/nickrob/ GNU gdb 6.6-debian ... (gdb) source myscript but, in any case, M-x gdba is probably more convenient. I think that M-x gdb doesn't work in you start execution from within a script. In this case you must use M-x gdba. Does this work? Yes! What's the difference betweeen gdb and gdba? I wasn't able to find anything documenting the difference, according to the docs they seem to do roughly the same thing. M-x gdba assumes that GDB is being run with the --annotate=3 option. M-x gdb filters the output to determine whether GDB is being run with --fullname or --annotate=3. The former gives the old Emacs 21 functionality (or lack of it!) and is worth using if all else fails. So they do indeed do the same thing, in most cases, when --annotate=3 is used (the default). There is a problem when GDB commands like run are included in GDB scripts because these get run _before_ GDB commands that Emacs uses to set up the mode. Perhaps I'll add a note in the manual. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
