[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Guilhem Bichot
Subject: 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
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0


Eli Zaretskii a écrit le 07/06/2016 19:15 :
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
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:


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.


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
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.

Attachment: Capture du 2016-06-09 10-10-15.png
Description: PNG image

reply via email to

[Prev in Thread] Current Thread [Next in Thread]