bug#23720: 25.0.94; Issues with GUD (gdb-mi) after upgrade from Emacs 23 to 24/25

bug#23720: 25.0.94; Issues with GUD (gdb-mi) after upgrade from Emacs 23 to 24/25

[Guilhem Bichot]

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@oracle.com>
Oracle / MySQL / Optimizer team, Lead Software Engineer
Bordeaux, France
www.oracle.com / www.mysql.com
http://guilhembichot.blogspot.com/

bug#23720: 25.0.94; Issues with GUD (gdb-mi) after upgrade from Emacs 23 to 24/25

[Eli Zaretskii]

> From: Guilhem Bichot <guilhem.bichot@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#23720: 25.0.94; Issues with GUD (gdb-mi) after upgrade from Emacs 23 to 24/25

[Eli Zaretskii]

> Date: Tue, 07 Jun 2016 20:15:34 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 23720@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#23720: 25.0.94; Issues with GUD (gdb-mi) after upgrade from Emacs 23 to 24/25

[Guilhem Bichot]

Hello,

Eli Zaretskii a écrit le 07/06/2016 20:54 :
>> Date: Tue, 07 Jun 2016 20:15:34 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: 23720@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#23720: 25.0.94; Issues with GUD (gdb-mi) after upgrade from Emacs 23 to 24/25

[Eli Zaretskii]

> Cc: 23720@debbugs.gnu.org
> From: Guilhem Bichot <guilhem.bichot@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#23720: 25.0.94; Issues with GUD (gdb-mi) after upgrade from Emacs 23 to 24/25

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@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

bug#23720: 25.0.94; Issues with GUD (gdb-mi) after upgrade from Emacs 23 to 24/25

[Guilhem Bichot]

[-- Attachment #1: Type: text/plain, Size: 4856 bytes --]

Hello,

Eli Zaretskii a écrit le 07/06/2016 19:15 :
>> From: Guilhem Bichot <guilhem.bichot@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.

[-- Attachment #2: Capture du 2016-06-09 10-10-15.png --]
[-- Type: image/png, Size: 44622 bytes --]

bug#23720: 25.0.94; Issues with GUD (gdb-mi) after upgrade from Emacs 23 to 24/25

[Eli Zaretskii]

> Cc: 23720@debbugs.gnu.org
> From: Guilhem Bichot <guilhem.bichot@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#23720: 25.0.94; Issues with GUD (gdb-mi) after upgrade from Emacs 23 to 24/25

[Guilhem Bichot]

Hello,

Eli Zaretskii a écrit le 09/06/2016 14:17 :
>> Cc: 23720@debbugs.gnu.org
>> From: Guilhem Bichot <guilhem.bichot@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#23720: 25.0.94; Issues with GUD (gdb-mi) after upgrade from Emacs 23 to 24/25

[Eli Zaretskii]

> Cc: 23720@debbugs.gnu.org
> From: Guilhem Bichot <guilhem.bichot@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#23720: 25.0.94; Issues with GUD (gdb-mi) after upgrade from Emacs 23 to 24/25

[Guilhem Bichot]

Eli Zaretskii a écrit le 09/06/2016 16:12 :
>> Cc: 23720@debbugs.gnu.org
>> From: Guilhem Bichot <guilhem.bichot@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#23720: 25.0.94; Issues with GUD (gdb-mi) after upgrade from Emacs 23 to 24/25

[Eli Zaretskii]

> Cc: 23720@debbugs.gnu.org
> From: Guilhem Bichot <guilhem.bichot@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#23720: 25.0.94; Issues with GUD (gdb-mi) after upgrade from Emacs 23 to 24/25

[Guilhem Bichot]

Hello,

Eli Zaretskii a écrit le 09/06/2016 16:36 :
>> Cc: 23720@debbugs.gnu.org
>> From: Guilhem Bichot <guilhem.bichot@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#23720: 25.0.94; Issues with GUD (gdb-mi) after upgrade from Emacs 23 to 24/25

[Eli Zaretskii]

> Cc: 23720@debbugs.gnu.org
> From: Guilhem Bichot <guilhem.bichot@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.