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

Previous Next

Package: emacs;

Reported by: Guilhem Bichot <guilhem.bichot <at> oracle.com>

Date: Tue, 7 Jun 2016 15:34:01 UTC

Severity: minor

Found in version 25.0.94

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Guilhem Bichot <guilhem.bichot <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23720 <at> debbugs.gnu.org
Subject: bug#23720: 25.0.94; Issues with GUD (gdb-mi) after upgrade from Emacs 23 to 24/25
Date: Thu, 9 Jun 2016 15:46:50 +0200
Hello,

Eli Zaretskii a écrit le 09/06/2016 14:17 :
>> Cc: 23720 <at> debbugs.gnu.org
>> From: Guilhem Bichot <guilhem.bichot <at> 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?




This bug report was last modified 4 years and 328 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.