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

[Guilhem Bichot <guilhem.bichot@oracle.com>]

[-- 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 --]