From: Guilhem Bichot <address@hidden>
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
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 2: FRAMES MOVING AROUND
After a "c"(continue) above, now MySQL is resumed, waiting for
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
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
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
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
See above: you shouldn't need to. I don't.