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.