Package: emacs;
Reported by: Guilhem Bichot <guilhem.bichot <at> oracle.com>
Date: Tue, 7 Jun 2016 15:34:01 UTC
Severity: minor
Found in version 25.0.94
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 23720 in the body.
You can then email your comments to 23720 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
bug-gnu-emacs <at> gnu.org
:bug#23720
; Package emacs
.
(Tue, 07 Jun 2016 15:34:01 GMT) Full text and rfc822 format available.Guilhem Bichot <guilhem.bichot <at> oracle.com>
:bug-gnu-emacs <at> gnu.org
.
(Tue, 07 Jun 2016 15:34:02 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Guilhem Bichot <guilhem.bichot <at> oracle.com> To: bug-gnu-emacs <at> gnu.org Subject: 25.0.94; Issues with GUD (gdb-mi) after upgrade from Emacs 23 to 24/25 Date: Tue, 7 Jun 2016 11:30:06 +0200
Hello. [ Thank you for all the work on Emacs, it so much helps my daily work ] I'm debugging the MySQL Server with "M-x gdb". Works great in Emacs23, for years. But it seems to break with upgrade to 24 (package of Ubuntu 15.10), and similarly in 25 pretest built-from-source. Here is my experience today with emacs 25; it's been consistently my experience for the last months, and a colleague has seen this too. Using "emacs -Q". M-x gdb, then I chdir to the directory where MySQL is, then "file ./mysqld". Using all-stop mode (that is the default choice). After issuing the "run" command, MySQL is waiting for client connections. Ok so far. ISSUE 1: STOPPING ================= STOP button doesn't stop (prints "command: -exec-interrupt") Menu Signals->STOP doesn't stop. C-c C-z doesn't stop. (In Emacs23 the STOP button did stop and it was sending SIGINT) Menu Signals->Break, or C-c C-c, stop properly. Suggestion: make the STOP button do as Signals->Break does (=send SIGINT), and like it did in emacs23. Perhaps another factor is MySQL ignoring STOP, but I don't think so, as doing 'kill -STOP' to the PID of mysql, in a shell, does stop it (but then it's hell to resume it, have to press "continue" for tens of times, perhaps because it has tens of threads). ISSUE 2: FRAMES MOVING AROUND ============================= After a "c"(continue) above, now MySQL is resumed, waiting for client connections. I wish to set a breakpoint. I do C-c C-c to interrupt, then in the menu Gud->gdb-mi->"display other windows": screen gets split in 6 frames (ok). All frames show the same gdb output. In the middle left frame, I open a source file (C-x C-f). I click in the left fringe near a code line: no breakpoint gets set alas. I put cursor on that line, press C-x SPC: prints "mark set (rectangle mode)"; doesn't set breakpoint either. (Both techniques worked in emacs23.) When putting the cursor in the source file, GUD-specific menu is replaced by ordinary menu; like if GUD wasn't considering this file. However, C-x C-a C-b sets breakpoint. After the breakpoint is set, I type "c". Run a MySQL query, gdb stops at breakpoint. Then, clicking on left fringe near a code line in the same source file, few lines below the breakpoint, sets a breakpoint: unlike at the first try above, it works. Like if GUD was now considering the file, now that it has broken into it? MySQL is stopped at the breakpoint. I click the "step line" button: as this stepping leads to another function in another source file, that other source file is opened (fine) but in the "breakpoints" frame (bottom right frame); this has the effect that: - breakpoints list is invisible - I'm always scanning through frames with my eyes to find where the execution pointer is now. (In Emacs23, the new file just replaces the old file. And when stepping out later, the old file would replace the new file). I do "restore window layout" which properly restores the "breakpoints" list in its frame, and puts the stepped-in file in the middle left. It's a workaround, but it's tedious as I have to do it frequently. ISSUE 3: STEPPING OUT DOESN'T PRINT RETURN VALUE ================================================ The program is in the stepped-in function, clicking "Step out" steps out of it, but this doesn't print the returned value. Emacs23 prints it ("Value returned is $1 = false"). After "c" the query finishes. I send the same query again, but this time the issue 2 doesn't happen anymore (i.e. the stepped-in source file is displayed where it should, replacing the old file, and not in the "breakpoints" frame). Using "GNU gdb (Ubuntu 7.10-1ubuntu2) 7.10" Sames issues with "GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.16.6) of 2015-09-17 on lgw01-52, modified by Debian" As workaround, I'm currently using a built-from-source 23.4.1 which works fine. In GNU Emacs 25.0.94.1 (x86_64-unknown-linux-gnu, X toolkit, Xaw scroll bars) of 2016-06-07 built on t3500 Windowing system distributor 'The X.Org Foundation', version 11.0.11702000 System Description: Ubuntu 15.10 Configured features: XPM JPEG TIFF GIF PNG SOUND NOTIFY ZLIB TOOLKIT_SCROLL_BARS LUCID X11 Important settings: value of $LANG: fr_FR.UTF-8 value of $XMODIFIERS: @im=ibus locale-coding-system: utf-8-unix Major mode: Debugger Minor modes in effect: gdb-many-windows: t diff-auto-refine-mode: t tooltip-mode: t global-eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Recent messages: Command: -exec-next 1 [2 times] Command: -exec-step 1 Command: -exec-finish Command: -exec-step 1 Command: -exec-next 1 [4 times] Command: -exec-finish Command: -exec-step 1 [3 times] Auto-saving... Making completion list... After 0 kbd macro iterations: mouse-posn-property: Args out of range: 7601 Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message dired format-spec rfc822 mml mml-sec password-cache epg epg-config gnus-util mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util help-fns mail-prsvr mail-utils rect misearch multi-isearch cus-start cus-load kmacro cl-seq gdb-mi bindat json map seq byte-opt gv bytecomp byte-compile cconv gud comint ansi-color ring vc-git diff-mode easy-mmode cl-extra help-mode cc-mode cc-fonts easymenu cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs cl-loaddefs pcase cl-lib time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote inotify dynamic-setting x-toolkit x multi-tty make-network-process emacs) Memory information: ((conses 16 162903 9524) (symbols 48 25219 0) (miscs 40 193 205) (strings 32 31416 5195) (string-bytes 1 976520) (vectors 16 18314) (vector-slots 8 503194 5768) (floats 8 233 199) (intervals 56 3629 313) (buffers 976 26) (heap 1024 38968 11749)) -- Mr. Guilhem Bichot <guilhem.bichot <at> oracle.com> Oracle / MySQL / Optimizer team, Lead Software Engineer Bordeaux, France www.oracle.com / www.mysql.com http://guilhembichot.blogspot.com/
bug-gnu-emacs <at> gnu.org
:bug#23720
; Package emacs
.
(Tue, 07 Jun 2016 17:16:02 GMT) Full text and rfc822 format available.Message #8 received at 23720 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Guilhem Bichot <guilhem.bichot <at> oracle.com> Cc: 23720 <at> debbugs.gnu.org Subject: Re: bug#23720: 25.0.94; Issues with GUD (gdb-mi) after upgrade from Emacs 23 to 24/25 Date: Tue, 07 Jun 2016 20:15:34 +0300
> From: Guilhem Bichot <guilhem.bichot <at> oracle.com> > Date: Tue, 7 Jun 2016 11:30:06 +0200 > > I'm debugging the MySQL Server with "M-x gdb". > Works great in Emacs23, for years. But it seems to break with upgrade to > 24 (package of Ubuntu 15.10), and similarly in 25 pretest > built-from-source. Here is my experience today with emacs 25; it's been > consistently my experience for the last months, and a colleague has seen > this too. Emacs 24 switched to a different GUD interface (and a different GDB interpreter, called MI) by default, and I believe most if not all of your problems happen because you try using that as if you were still working with the previous interface based on annotations. That old interface is still there, so if you decide you don't want to learn the new one, you can simply start GDB with M-x gud-gdb RET and will have your familiar debugging environment back. > ISSUE 1: STOPPING > ================= > > STOP button doesn't stop (prints "command: -exec-interrupt") "-exec-interrupt" is the MI equivalent of the GDB "interrupt" command, so it should do exactly what you want. > Menu Signals->STOP doesn't stop. > C-c C-z doesn't stop. That menu and "C-c C-z" are not relevant to debugging. When you are debugging, they will attempt to stop the debugger. > (In Emacs23 the STOP button did stop and it was sending > SIGINT) That's STOP _button_, not the menu item. The STOP menu item does exist in Emacs 23, and it behaves exactly like it does in Emacs 24 and 25. > Menu Signals->Break, or C-c C-c, stop properly. > > Suggestion: make the STOP button do as Signals->Break does > (=send SIGINT), and like it did in emacs23. There's no STOP button on the gdb-mi toolbar, I guess you mean add it? > Perhaps another factor is MySQL ignoring STOP, but I don't think so, as > doing 'kill -STOP' to the PID of mysql, in a shell, does stop it (but > then it's hell to resume it, have to press "continue" for tens of times, > perhaps because it has tens of threads). Please do find out whether MySQL ignores STOP (or maybe TSTP?). I'd like to be sure what are the real issues. > ISSUE 2: FRAMES MOVING AROUND > ============================= > > After a "c"(continue) above, now MySQL is resumed, waiting for > client connections. > I wish to set a breakpoint. > > I do C-c C-c to interrupt, then in the menu Gud->gdb-mi->"display other > windows": screen gets split in 6 frames (ok). > All frames show the same gdb output. You should generally invoke gdb-many-windows before starting the actual debugging. > In the middle left frame, I open a source file (C-x C-f). > I click in the left fringe near a code line: no breakpoint gets set > alas. > I put cursor on that line, press C-x SPC: prints "mark set (rectangle > mode)"; doesn't set breakpoint either. > (Both techniques worked in emacs23.) It sounds like your debuggee program is running, which is why you don't see the breakpoint feedback. I think you need to stop the program first, and then insert breakpoints. (I never debug in async mode, so I'm not 100% sure in what I say, but I think I'm right.) > When putting the cursor in the source file, GUD-specific menu is > replaced by ordinary menu; like if GUD wasn't considering this file. Yes, because you opened the source file yourself. It is best to start the debuggee with a "start" command (rather than "run"), and then open sources in the same window where Emacs shows the source of the current function. > However, C-x C-a C-b sets breakpoint. > > After the breakpoint is set, I type "c". > Run a MySQL query, gdb stops at breakpoint. > Then, clicking on left fringe near a code line in the same source > file, few lines below the breakpoint, sets a breakpoint: unlike at the > first try above, it works. Like if GUD was now considering the file, now > that it has broken into it? I believe that's because MySQL is now stopped, see above. > MySQL is stopped at the breakpoint. I click the "step line" button: as > this stepping leads to another function in another source file, that > other source file is opened (fine) but in the "breakpoints" frame > (bottom right frame); this has the effect that: > - breakpoints list is invisible > - I'm always scanning through frames with my eyes to find where the > execution pointer is now. This never happens to me. Please try this again, but this time invoke gdb-many-windows before actually debugging, after entering the debugger and getting the prompt. If it still doesn't work, I suspect some of your customizations, so please try in "emacs -Q". > (In Emacs23, the new file just replaces the old file. And when stepping > out later, the old file would replace the new file). That's what I see here with the latest Emacs 25. > I do "restore window layout" which properly restores the > "breakpoints" list in its frame, and puts the stepped-in file in the > middle left. It's a workaround, but it's tedious as I have to do it > frequently. See above: you shouldn't need to. I don't. > ISSUE 3: STEPPING OUT DOESN'T PRINT RETURN VALUE > ================================================ > > The program is in the stepped-in function, clicking "Step out" steps out > of it, but this doesn't print the returned value. > Emacs23 prints it ("Value returned is $1 = false"). Looks like a missing feature in gdb-mi: the return value sent by MI is not processed. > After "c" the query finishes. I send the same query again, but this > time the issue 2 doesn't happen anymore (i.e. the stepped-in > source file is displayed where it should, replacing the old file, and > not in the "breakpoints" frame). For me, it always works like this. Thanks.
bug-gnu-emacs <at> gnu.org
:bug#23720
; Package emacs
.
(Tue, 07 Jun 2016 18:55:01 GMT) Full text and rfc822 format available.Message #11 received at 23720 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: guilhem.bichot <at> oracle.com Cc: 23720 <at> debbugs.gnu.org Subject: Re: bug#23720: 25.0.94; Issues with GUD (gdb-mi) after upgrade from Emacs 23 to 24/25 Date: Tue, 07 Jun 2016 21:54:58 +0300
> Date: Tue, 07 Jun 2016 20:15:34 +0300 > From: Eli Zaretskii <eliz <at> gnu.org> > Cc: 23720 <at> debbugs.gnu.org > > > ISSUE 3: STEPPING OUT DOESN'T PRINT RETURN VALUE > > ================================================ > > > > The program is in the stepped-in function, clicking "Step out" steps out > > of it, but this doesn't print the returned value. > > Emacs23 prints it ("Value returned is $1 = false"). > > Looks like a missing feature in gdb-mi: the return value sent by MI is > not processed. Please try the patch below, I think it will fix this. diff --git a/lisp/progmodes/gdb-mi.el b/lisp/progmodes/gdb-mi.el index 5ad101d..195acaf 100644 --- a/lisp/progmodes/gdb-mi.el +++ b/lisp/progmodes/gdb-mi.el @@ -2488,7 +2488,9 @@ gdb-stopped ;; Reason is available with target-async only (let* ((result (gdb-json-string output-field)) (reason (bindat-get-field result 'reason)) - (thread-id (bindat-get-field result 'thread-id))) + (thread-id (bindat-get-field result 'thread-id)) + (retval (bindat-get-field result 'return-value)) + (varnum (bindat-get-field result 'gdb-result-var))) ;; -data-list-register-names needs to be issued for any stopped ;; thread @@ -2514,6 +2516,11 @@ gdb-stopped (if (string-equal reason "exited-normally") (setq gdb-active-process nil)) + (when (and retval varnum) + (setq gdb-filter-output + (concat gdb-filter-output + (format "Value returned is %s = %s\n" varnum retval)))) + ;; Select new current thread. ;; Don't switch if we have no reasons selected
bug-gnu-emacs <at> gnu.org
:bug#23720
; Package emacs
.
(Thu, 09 Jun 2016 07:43:02 GMT) Full text and rfc822 format available.Message #14 received at 23720 <at> debbugs.gnu.org (full text, mbox):
From: Guilhem Bichot <guilhem.bichot <at> oracle.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 23720 <at> debbugs.gnu.org Subject: Re: bug#23720: 25.0.94; Issues with GUD (gdb-mi) after upgrade from Emacs 23 to 24/25 Date: Thu, 9 Jun 2016 09:42:23 +0200
Hello, Eli Zaretskii a écrit le 07/06/2016 20:54 : >> Date: Tue, 07 Jun 2016 20:15:34 +0300 >> From: Eli Zaretskii <eliz <at> gnu.org> >> Cc: 23720 <at> debbugs.gnu.org >> >>> ISSUE 3: STEPPING OUT DOESN'T PRINT RETURN VALUE >>> ================================================ >>> >>> The program is in the stepped-in function, clicking "Step out" steps out >>> of it, but this doesn't print the returned value. >>> Emacs23 prints it ("Value returned is $1 = false"). >> >> Looks like a missing feature in gdb-mi: the return value sent by MI is >> not processed. > > Please try the patch below, I think it will fix this. > > diff --git a/lisp/progmodes/gdb-mi.el b/lisp/progmodes/gdb-mi.el > index 5ad101d..195acaf 100644 > --- a/lisp/progmodes/gdb-mi.el > +++ b/lisp/progmodes/gdb-mi.el > @@ -2488,7 +2488,9 @@ gdb-stopped > ;; Reason is available with target-async only > (let* ((result (gdb-json-string output-field)) > (reason (bindat-get-field result 'reason)) > - (thread-id (bindat-get-field result 'thread-id))) > + (thread-id (bindat-get-field result 'thread-id)) > + (retval (bindat-get-field result 'return-value)) > + (varnum (bindat-get-field result 'gdb-result-var))) > > ;; -data-list-register-names needs to be issued for any stopped > ;; thread > @@ -2514,6 +2516,11 @@ gdb-stopped > (if (string-equal reason "exited-normally") > (setq gdb-active-process nil)) > > + (when (and retval varnum) > + (setq gdb-filter-output > + (concat gdb-filter-output > + (format "Value returned is %s = %s\n" varnum retval)))) > + > ;; Select new current thread. > > ;; Don't switch if we have no reasons selected yes, it works! thanks! Please, could you consider incorporating this into the next releases?
bug-gnu-emacs <at> gnu.org
:bug#23720
; Package emacs
.
(Thu, 09 Jun 2016 08:16:01 GMT) Full text and rfc822 format available.Message #17 received at 23720 <at> debbugs.gnu.org (full text, mbox):
From: Guilhem Bichot <guilhem.bichot <at> oracle.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 23720 <at> debbugs.gnu.org Subject: Re: bug#23720: 25.0.94; Issues with GUD (gdb-mi) after upgrade from Emacs 23 to 24/25 Date: Thu, 9 Jun 2016 10:14:55 +0200
[Message part 1 (text/plain, inline)]
Hello, Eli Zaretskii a écrit le 07/06/2016 19:15 : >> From: Guilhem Bichot <guilhem.bichot <at> oracle.com> >> Date: Tue, 7 Jun 2016 11:30:06 +0200 >> >> I'm debugging the MySQL Server with "M-x gdb". >> Works great in Emacs23, for years. But it seems to break with upgrade to >> 24 (package of Ubuntu 15.10), and similarly in 25 pretest >> built-from-source. Here is my experience today with emacs 25; it's been >> consistently my experience for the last months, and a colleague has seen >> this too. > > Emacs 24 switched to a different GUD interface (and a different GDB > interpreter, called MI) by default, and I believe most if not all of > your problems happen because you try using that as if you were still > working with the previous interface based on annotations. That old > interface is still there, so if you decide you don't want to learn the > new one, you can simply start GDB with > > M-x gud-gdb RET > > and will have your familiar debugging environment back. Not quite. Even with gud-gdb, some scenarios described below (ISSUE 2) still happen: - with emacs25 C-x SPC doesn't set a breakpoint; with emacs23 it does. - Same for "clicking on the fringe doesn't set breakpoint". - the Gud menu has lost "display other windows" Before digging more in the gdb-mi discussion below, let's address one striking point, to be sure we're talking about the same software: >> ISSUE 1: STOPPING >> ================= >> Suggestion: make the STOP button do as Signals->Break does >> (=send SIGINT), and like it did in emacs23. > > There's no STOP button on the gdb-mi toolbar, I guess you mean add it? There is such button; after running "M-x gdb" (which says it will run "gdb -i=mi", so I imagine it's gdb-mi), there is a green GO button; when running the program, this button becomes a red STOP button. Attached is a screenshot, with the mouse pointer on the button. >> ISSUE 2: FRAMES MOVING AROUND >> ============================= >> >> After a "c"(continue) above, now MySQL is resumed, waiting for >> client connections. >> I wish to set a breakpoint. >> >> I do C-c C-c to interrupt, then in the menu Gud->gdb-mi->"display other >> windows": screen gets split in 6 frames (ok). >> All frames show the same gdb output. > > You should generally invoke gdb-many-windows before starting the > actual debugging. > >> In the middle left frame, I open a source file (C-x C-f). >> I click in the left fringe near a code line: no breakpoint gets set >> alas. >> I put cursor on that line, press C-x SPC: prints "mark set (rectangle >> mode)"; doesn't set breakpoint either. >> (Both techniques worked in emacs23.) > > It sounds like your debuggee program is running, which is why you > don't see the breakpoint feedback. I think you need to stop the > program first, and then insert breakpoints. (I never debug in async > mode, so I'm not 100% sure in what I say, but I think I'm right.) > >> When putting the cursor in the source file, GUD-specific menu is >> replaced by ordinary menu; like if GUD wasn't considering this file. > > Yes, because you opened the source file yourself. It is best to start > the debuggee with a "start" command (rather than "run"), and then open > sources in the same window where Emacs shows the source of the current > function. > >> However, C-x C-a C-b sets breakpoint. >> >> After the breakpoint is set, I type "c". >> Run a MySQL query, gdb stops at breakpoint. >> Then, clicking on left fringe near a code line in the same source >> file, few lines below the breakpoint, sets a breakpoint: unlike at the >> first try above, it works. Like if GUD was now considering the file, now >> that it has broken into it? > > I believe that's because MySQL is now stopped, see above. > >> MySQL is stopped at the breakpoint. I click the "step line" button: as >> this stepping leads to another function in another source file, that >> other source file is opened (fine) but in the "breakpoints" frame >> (bottom right frame); this has the effect that: >> - breakpoints list is invisible >> - I'm always scanning through frames with my eyes to find where the >> execution pointer is now. > > This never happens to me. Please try this again, but this time invoke > gdb-many-windows before actually debugging, after entering the > debugger and getting the prompt. If it still doesn't work, I suspect > some of your customizations, so please try in "emacs -Q". > >> (In Emacs23, the new file just replaces the old file. And when stepping >> out later, the old file would replace the new file). > > That's what I see here with the latest Emacs 25. > >> I do "restore window layout" which properly restores the >> "breakpoints" list in its frame, and puts the stepped-in file in the >> middle left. It's a workaround, but it's tedious as I have to do it >> frequently. > > See above: you shouldn't need to. I don't.
[Capture du 2016-06-09 10-10-15.png (image/png, attachment)]
bug-gnu-emacs <at> gnu.org
:bug#23720
; Package emacs
.
(Thu, 09 Jun 2016 12:18:01 GMT) Full text and rfc822 format available.Message #20 received at 23720 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Guilhem Bichot <guilhem.bichot <at> oracle.com> Cc: 23720 <at> debbugs.gnu.org Subject: Re: bug#23720: 25.0.94; Issues with GUD (gdb-mi) after upgrade from Emacs 23 to 24/25 Date: Thu, 09 Jun 2016 15:17:58 +0300
> Cc: 23720 <at> debbugs.gnu.org > From: Guilhem Bichot <guilhem.bichot <at> oracle.com> > Date: Thu, 9 Jun 2016 10:14:55 +0200 > > > M-x gud-gdb RET > > > > and will have your familiar debugging environment back. > > Not quite. Even with gud-gdb, some scenarios described below (ISSUE 2) > still happen: > - with emacs25 C-x SPC doesn't set a breakpoint; with emacs23 it does. > - Same for "clicking on the fringe doesn't set breakpoint". > - the Gud menu has lost "display other windows" Like I said, I believe this is because your program is running. When I start the debugger, before the "run" command, breakpoints do work as expected. > Before digging more in the gdb-mi discussion below, let's address one > striking point, to be sure we're talking about the same software: > > >> ISSUE 1: STOPPING > >> ================= > > >> Suggestion: make the STOP button do as Signals->Break does > >> (=send SIGINT), and like it did in emacs23. > > > > There's no STOP button on the gdb-mi toolbar, I guess you mean add it? > > There is such button; after running "M-x gdb" (which says it will run > "gdb -i=mi", so I imagine it's gdb-mi), there is a green GO button; when > running the program, this button becomes a red STOP button. Attached is > a screenshot, with the mouse pointer on the button. This button invokes -exec-interrupt when you use gdb-mi, which is the equivalent of the 'interrupt' command of GDB.
bug-gnu-emacs <at> gnu.org
:bug#23720
; Package emacs
.
(Thu, 09 Jun 2016 13:48:02 GMT) Full text and rfc822 format available.Message #23 received at 23720 <at> debbugs.gnu.org (full text, mbox):
From: Guilhem Bichot <guilhem.bichot <at> oracle.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 23720 <at> debbugs.gnu.org Subject: Re: bug#23720: 25.0.94; Issues with GUD (gdb-mi) after upgrade from Emacs 23 to 24/25 Date: Thu, 9 Jun 2016 15:46:50 +0200
Hello, Eli Zaretskii a écrit le 09/06/2016 14:17 : >> Cc: 23720 <at> debbugs.gnu.org >> From: Guilhem Bichot <guilhem.bichot <at> oracle.com> >> Date: Thu, 9 Jun 2016 10:14:55 +0200 >> >>> M-x gud-gdb RET >>> >>> and will have your familiar debugging environment back. >> >> Not quite. Even with gud-gdb, some scenarios described below (ISSUE 2) >> still happen: >> - with emacs25 C-x SPC doesn't set a breakpoint; with emacs23 it does. >> - Same for "clicking on the fringe doesn't set breakpoint". >> - the Gud menu has lost "display other windows" > > Like I said, I believe this is because your program is running. It is not running. I can repeat the problem when the display is: Breakpoint 1, JOIN::exec (this=0x7fff70008770) at /home/mysql_src/git/cte/sql/sql_executor.cc:113 113 { (gdb) which very much suggests the program is currently stopped (thus, not running). At that point, I can open another file, and put the cursor on a line of that file, and: - C-x C-a C-b does set the breakpoint (another hint that the program isn't stopped). - C-x SPC and clicking on the fringe, don't. In emacs23 they do. In other words, gdb-mi sees manually-opened-files as "not my business I won't offer my shortcuts there", while gud-gdb sees it differently. The latter is more convenient. It is not possible to know in advance all the breakpoints one will need and set them all before "run"... > When > I start the debugger, before the "run" command, breakpoints do work as > expected. > >> Before digging more in the gdb-mi discussion below, let's address one >> striking point, to be sure we're talking about the same software: >> >>>> ISSUE 1: STOPPING >>>> ================= >> >>>> Suggestion: make the STOP button do as Signals->Break does >>>> (=send SIGINT), and like it did in emacs23. >>> >>> There's no STOP button on the gdb-mi toolbar, I guess you mean add it? >> >> There is such button; after running "M-x gdb" (which says it will run >> "gdb -i=mi", so I imagine it's gdb-mi), there is a green GO button; when >> running the program, this button becomes a red STOP button. Attached is >> a screenshot, with the mouse pointer on the button. > > This button invokes -exec-interrupt when you use gdb-mi, which is the > equivalent of the 'interrupt' command of GDB. ok, now we agree there's a STOP button in emacs24. (gdb) help interrupt Interrupt the execution of the debugged program. So, shouldn't this STOP button interrupt my debugged, running program (mysql)? Pressing this STOP button in emacs23 does interrupt it. It doesn't anymore in emacs24. Is it considered normal?
bug-gnu-emacs <at> gnu.org
:bug#23720
; Package emacs
.
(Thu, 09 Jun 2016 14:13:01 GMT) Full text and rfc822 format available.Message #26 received at 23720 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Guilhem Bichot <guilhem.bichot <at> oracle.com> Cc: 23720 <at> debbugs.gnu.org Subject: Re: bug#23720: 25.0.94; Issues with GUD (gdb-mi) after upgrade from Emacs 23 to 24/25 Date: Thu, 09 Jun 2016 17:12:32 +0300
> Cc: 23720 <at> debbugs.gnu.org > From: Guilhem Bichot <guilhem.bichot <at> oracle.com> > Date: Thu, 9 Jun 2016 15:46:50 +0200 > > > Like I said, I believe this is because your program is running. > > It is not running. I can repeat the problem when the display is: > Breakpoint 1, JOIN::exec (this=0x7fff70008770) at > /home/mysql_src/git/cte/sql/sql_executor.cc:113 > 113 { > (gdb) > > which very much suggests the program is currently stopped (thus, not > running). At that point, I can open another file, and put the cursor on > a line of that file, and: > - C-x C-a C-b does set the breakpoint (another hint that the program > isn't stopped). > - C-x SPC and clicking on the fringe, don't. In emacs23 they do. > > In other words, gdb-mi sees manually-opened-files as "not my business I > won't offer my shortcuts there", while gud-gdb sees it differently. The > latter is more convenient. > > It is not possible to know in advance all the breakpoints one will need > and set them all before "run"... Ah, okay, I've misunderstood you, sorry. Yes, this is how stuff works with gdb-mi. > ok, now we agree there's a STOP button in emacs24. > > (gdb) help interrupt > Interrupt the execution of the debugged program. > > So, shouldn't this STOP button interrupt my debugged, running program > (mysql)? > Pressing this STOP button in emacs23 does interrupt it. > It doesn't anymore in emacs24. > Is it considered normal? I don't think so, but I don't have any more wisdom to offer about this. AFAIU, -exec-interrupt should have interrupted your program, unless it masks signals.
bug-gnu-emacs <at> gnu.org
:bug#23720
; Package emacs
.
(Thu, 09 Jun 2016 14:31:02 GMT) Full text and rfc822 format available.Message #29 received at 23720 <at> debbugs.gnu.org (full text, mbox):
From: Guilhem Bichot <guilhem.bichot <at> oracle.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 23720 <at> debbugs.gnu.org Subject: Re: bug#23720: 25.0.94; Issues with GUD (gdb-mi) after upgrade from Emacs 23 to 24/25 Date: Thu, 9 Jun 2016 16:30:16 +0200
Eli Zaretskii a écrit le 09/06/2016 16:12 : >> Cc: 23720 <at> debbugs.gnu.org >> From: Guilhem Bichot <guilhem.bichot <at> oracle.com> >> Date: Thu, 9 Jun 2016 15:46:50 +0200 >> >>> Like I said, I believe this is because your program is running. >> >> It is not running. I can repeat the problem when the display is: >> Breakpoint 1, JOIN::exec (this=0x7fff70008770) at >> /home/mysql_src/git/cte/sql/sql_executor.cc:113 >> 113 { >> (gdb) >> >> which very much suggests the program is currently stopped (thus, not >> running). At that point, I can open another file, and put the cursor on >> a line of that file, and: >> - C-x C-a C-b does set the breakpoint (another hint that the program >> isn't stopped). >> - C-x SPC and clicking on the fringe, don't. In emacs23 they do. >> >> In other words, gdb-mi sees manually-opened-files as "not my business I >> won't offer my shortcuts there", while gud-gdb sees it differently. The >> latter is more convenient. >> >> It is not possible to know in advance all the breakpoints one will need >> and set them all before "run"... > > Ah, okay, I've misunderstood you, sorry. Yes, this is how stuff works > with gdb-mi. Ok. So, apparently, gdb-mi has a set of "source files it has visited" and treats other source files differently. >> ok, now we agree there's a STOP button in emacs24. >> >> (gdb) help interrupt >> Interrupt the execution of the debugged program. >> >> So, shouldn't this STOP button interrupt my debugged, running program >> (mysql)? >> Pressing this STOP button in emacs23 does interrupt it. >> It doesn't anymore in emacs24. >> Is it considered normal? > > I don't think so, but I don't have any more wisdom to offer about > this. AFAIU, -exec-interrupt should have interrupted your program, > unless it masks signals. I see. When I find the time, I'll try diff-ing the code of gud-gdb and of gdb-mi to find what magic the gud-gdb STOP button has, which makes it have "a stronger interruption effect". If I find anything, I'll report it here. Thanks for your help!
bug-gnu-emacs <at> gnu.org
:bug#23720
; Package emacs
.
(Thu, 09 Jun 2016 14:36:01 GMT) Full text and rfc822 format available.Message #32 received at 23720 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Guilhem Bichot <guilhem.bichot <at> oracle.com> Cc: 23720 <at> debbugs.gnu.org Subject: Re: bug#23720: 25.0.94; Issues with GUD (gdb-mi) after upgrade from Emacs 23 to 24/25 Date: Thu, 09 Jun 2016 17:36:20 +0300
> Cc: 23720 <at> debbugs.gnu.org > From: Guilhem Bichot <guilhem.bichot <at> oracle.com> > Date: Thu, 9 Jun 2016 16:30:16 +0200 > > >> Pressing this STOP button in emacs23 does interrupt it. > >> It doesn't anymore in emacs24. > >> Is it considered normal? > > > > I don't think so, but I don't have any more wisdom to offer about > > this. AFAIU, -exec-interrupt should have interrupted your program, > > unless it masks signals. > > I see. When I find the time, I'll try diff-ing the code of gud-gdb and > of gdb-mi to find what magic the gud-gdb STOP button has, which makes it > have "a stronger interruption effect". > If I find anything, I'll report it here. I think the answer to that is clear from this: (defun gud-stop-subjob () (interactive) (with-current-buffer gud-comint-buffer (cond ((string-equal gud-target-name "emacs") (comint-stop-subjob)) ((eq gud-minor-mode 'jdb) (gud-call "suspend")) ((eq gud-minor-mode 'gdbmi) (gud-call (gdb-gud-context-command "-exec-interrupt"))) (t (comint-interrupt-subjob))))) As you see i works differently depending on whether gdb-mi is used or not. What I don't understand is why -exec-interrupt doesn't do its job in your case.
bug-gnu-emacs <at> gnu.org
:bug#23720
; Package emacs
.
(Fri, 10 Jun 2016 08:42:01 GMT) Full text and rfc822 format available.Message #35 received at 23720 <at> debbugs.gnu.org (full text, mbox):
From: Guilhem Bichot <guilhem.bichot <at> oracle.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 23720 <at> debbugs.gnu.org Subject: Re: bug#23720: 25.0.94; Issues with GUD (gdb-mi) after upgrade from Emacs 23 to 24/25 Date: Fri, 10 Jun 2016 10:41:27 +0200
Hello, Eli Zaretskii a écrit le 09/06/2016 16:36 : >> Cc: 23720 <at> debbugs.gnu.org >> From: Guilhem Bichot <guilhem.bichot <at> oracle.com> >> Date: Thu, 9 Jun 2016 16:30:16 +0200 >> >>>> Pressing this STOP button in emacs23 does interrupt it. >>>> It doesn't anymore in emacs24. >>>> Is it considered normal? >>> >>> I don't think so, but I don't have any more wisdom to offer about >>> this. AFAIU, -exec-interrupt should have interrupted your program, >>> unless it masks signals. >> >> I see. When I find the time, I'll try diff-ing the code of gud-gdb and >> of gdb-mi to find what magic the gud-gdb STOP button has, which makes it >> have "a stronger interruption effect". >> If I find anything, I'll report it here. > > I think the answer to that is clear from this: > > (defun gud-stop-subjob () > (interactive) > (with-current-buffer gud-comint-buffer > (cond ((string-equal gud-target-name "emacs") > (comint-stop-subjob)) > ((eq gud-minor-mode 'jdb) > (gud-call "suspend")) > ((eq gud-minor-mode 'gdbmi) > (gud-call (gdb-gud-context-command "-exec-interrupt"))) > (t > (comint-interrupt-subjob))))) > > As you see i works differently depending on whether gdb-mi is used or > not. What I don't understand is why -exec-interrupt doesn't do its > job in your case. It's isn't mysql-related. I create the simple a.cc: int main() { long long int x; for (x= 1; x; x++) ; return 0; } I compile: g++ -g a.cc I open a.cc in emacs25, M-x gdb, "run"; it prints (gdb) r Starting program: /home/mysql_src/tmp/a.out the long "for" loop is running, I press the STOP button, it prints "command: -exec-interrupt", and the program apparently doesn't stop (as there is no change at the prompt). To be sure about "doesn't stop", I try with this program #include <iostream> #include <unistd.h> int main() { long long int x; for (x= 1; x; x++) { std::cout << x << std::endl; sleep(1); } return 0; } And, likewise, the printouts continue, undisturbed by the click on STOP. For what it's worth, the menu Signals->Break interrupts it and I properly get: Program received signal SIGINT, Interrupt. 0x0000000000400509 in main () at a.cc:4 4 for (x= 1; x; x++) (gdb) I'm using Ubuntu 15.10.
bug-gnu-emacs <at> gnu.org
:bug#23720
; Package emacs
.
(Fri, 10 Jun 2016 09:00:02 GMT) Full text and rfc822 format available.Message #38 received at 23720 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Guilhem Bichot <guilhem.bichot <at> oracle.com> Cc: 23720 <at> debbugs.gnu.org Subject: Re: bug#23720: 25.0.94; Issues with GUD (gdb-mi) after upgrade from Emacs 23 to 24/25 Date: Fri, 10 Jun 2016 12:00:07 +0300
> Cc: 23720 <at> debbugs.gnu.org > From: Guilhem Bichot <guilhem.bichot <at> oracle.com> > Date: Thu, 9 Jun 2016 09:42:23 +0200 > > > diff --git a/lisp/progmodes/gdb-mi.el b/lisp/progmodes/gdb-mi.el > > index 5ad101d..195acaf 100644 > > --- a/lisp/progmodes/gdb-mi.el > > +++ b/lisp/progmodes/gdb-mi.el > > @@ -2488,7 +2488,9 @@ gdb-stopped > > ;; Reason is available with target-async only > > (let* ((result (gdb-json-string output-field)) > > (reason (bindat-get-field result 'reason)) > > - (thread-id (bindat-get-field result 'thread-id))) > > + (thread-id (bindat-get-field result 'thread-id)) > > + (retval (bindat-get-field result 'return-value)) > > + (varnum (bindat-get-field result 'gdb-result-var))) > > > > ;; -data-list-register-names needs to be issued for any stopped > > ;; thread > > @@ -2514,6 +2516,11 @@ gdb-stopped > > (if (string-equal reason "exited-normally") > > (setq gdb-active-process nil)) > > > > + (when (and retval varnum) > > + (setq gdb-filter-output > > + (concat gdb-filter-output > > + (format "Value returned is %s = %s\n" varnum retval)))) > > + > > ;; Select new current thread. > > > > ;; Don't switch if we have no reasons selected > > yes, it works! thanks! > Please, could you consider incorporating this into the next releases? It's too late for the next release, which is expected in a few weeks. Besides, I've just discovered that sometimes the "Value returned" message as already produced by GDB/MI, so my naïve change caused it to be produced twice. I pushed a fixed version to the master branch.
bug-gnu-emacs <at> gnu.org
:bug#23720
; Package emacs
.
(Fri, 10 Jun 2016 09:52:01 GMT) Full text and rfc822 format available.Message #41 received at 23720 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Guilhem Bichot <guilhem.bichot <at> oracle.com> Cc: 23720 <at> debbugs.gnu.org Subject: Re: bug#23720: 25.0.94; Issues with GUD (gdb-mi) after upgrade from Emacs 23 to 24/25 Date: Fri, 10 Jun 2016 12:52:14 +0300
> Cc: 23720 <at> debbugs.gnu.org > From: Guilhem Bichot <guilhem.bichot <at> oracle.com> > Date: Fri, 10 Jun 2016 10:41:27 +0200 > > > (defun gud-stop-subjob () > > (interactive) > > (with-current-buffer gud-comint-buffer > > (cond ((string-equal gud-target-name "emacs") > > (comint-stop-subjob)) > > ((eq gud-minor-mode 'jdb) > > (gud-call "suspend")) > > ((eq gud-minor-mode 'gdbmi) > > (gud-call (gdb-gud-context-command "-exec-interrupt"))) > > (t > > (comint-interrupt-subjob))))) > > > > As you see i works differently depending on whether gdb-mi is used or > > not. What I don't understand is why -exec-interrupt doesn't do its > > job in your case. > > It's isn't mysql-related. I create the simple a.cc: > > int main() > { > long long int x; > for (x= 1; x; x++) > ; > return 0; > } > > I compile: > g++ -g a.cc > > I open a.cc in emacs25, M-x gdb, "run"; it prints > (gdb) r > Starting program: /home/mysql_src/tmp/a.out > > the long "for" loop is running, I press the STOP button, it prints > "command: -exec-interrupt", and the program apparently doesn't stop (as > there is no change at the prompt). To be sure about "doesn't stop", I > try with this program > > #include <iostream> > #include <unistd.h> > int main() > { > long long int x; > for (x= 1; x; x++) > { > std::cout << x << std::endl; > sleep(1); > } > return 0; > } > > And, likewise, the printouts continue, undisturbed by the click on STOP. > > For what it's worth, the menu Signals->Break interrupts it and I > properly get: > > Program received signal SIGINT, Interrupt. > 0x0000000000400509 in main () at a.cc:4 > 4 for (x= 1; x; x++) > (gdb) > > I'm using Ubuntu 15.10. I suggest to ask this question on the GDB mailing list.
bug-gnu-emacs <at> gnu.org
:bug#23720
; Package emacs
.
(Mon, 24 Aug 2020 18:17:01 GMT) Full text and rfc822 format available.Message #44 received at 23720 <at> debbugs.gnu.org (full text, mbox):
From: Lars Ingebrigtsen <larsi <at> gnus.org> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 23720 <at> debbugs.gnu.org, Guilhem Bichot <guilhem.bichot <at> oracle.com> Subject: Re: bug#23720: 25.0.94; Issues with GUD (gdb-mi) after upgrade from Emacs 23 to 24/25 Date: Mon, 24 Aug 2020 20:15:52 +0200
Eli Zaretskii <eliz <at> gnu.org> writes: > It's too late for the next release, which is expected in a few weeks. > Besides, I've just discovered that sometimes the "Value returned" > message as already produced by GDB/MI, so my naïve change caused it to > be produced twice. I pushed a fixed version to the master branch. If I'm skimming this thread correctly, this change fixed the reported bug, so I'm closing this bug report. If there's anything more to be worked on here, please send a mail to the debbugs address and we'll reopen the bug report. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
Lars Ingebrigtsen <larsi <at> gnus.org>
to control <at> debbugs.gnu.org
.
(Mon, 24 Aug 2020 18:17:02 GMT) Full text and rfc822 format available.Debbugs Internal Request <help-debbugs <at> gnu.org>
to internal_control <at> debbugs.gnu.org
.
(Tue, 22 Sep 2020 11:24:05 GMT) Full text and rfc822 format available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.