From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#23720: 25.0.94; Issues with GUD (gdb-mi) after upgrade from Emacs 23 to 24/25 Date: Tue, 07 Jun 2016 20:15:34 +0300 Message-ID: <837fe0syx5.fsf@gnu.org> References: <5756941E.3000700@oracle.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1465319790 14509 80.91.229.3 (7 Jun 2016 17:16:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 7 Jun 2016 17:16:30 +0000 (UTC) Cc: 23720@debbugs.gnu.org To: Guilhem Bichot Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jun 07 19:16:19 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bAKbx-0000xZ-54 for geb-bug-gnu-emacs@m.gmane.org; Tue, 07 Jun 2016 19:16:17 +0200 Original-Received: from localhost ([::1]:51770 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bAKbw-0003Q3-C6 for geb-bug-gnu-emacs@m.gmane.org; Tue, 07 Jun 2016 13:16:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43107) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bAKbn-0003O3-Sr for bug-gnu-emacs@gnu.org; Tue, 07 Jun 2016 13:16:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bAKbi-0000Iz-OZ for bug-gnu-emacs@gnu.org; Tue, 07 Jun 2016 13:16:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:46600) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bAKbi-0000Iv-LH for bug-gnu-emacs@gnu.org; Tue, 07 Jun 2016 13:16:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bAKbi-0004A9-CP for bug-gnu-emacs@gnu.org; Tue, 07 Jun 2016 13:16:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Jun 2016 17:16:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23720 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 23720-submit@debbugs.gnu.org id=B23720.146531971215932 (code B ref 23720); Tue, 07 Jun 2016 17:16:02 +0000 Original-Received: (at 23720) by debbugs.gnu.org; 7 Jun 2016 17:15:12 +0000 Original-Received: from localhost ([127.0.0.1]:58937 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bAKau-00048u-3n for submit@debbugs.gnu.org; Tue, 07 Jun 2016 13:15:12 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:51871) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bAKar-00048g-P6 for 23720@debbugs.gnu.org; Tue, 07 Jun 2016 13:15:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bAKai-00006h-JA for 23720@debbugs.gnu.org; Tue, 07 Jun 2016 13:15:04 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53189) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bAKai-00006a-FK; Tue, 07 Jun 2016 13:15:00 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4712 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bAKag-00082E-MY; Tue, 07 Jun 2016 13:14:59 -0400 In-reply-to: <5756941E.3000700@oracle.com> (message from Guilhem Bichot on Tue, 7 Jun 2016 11:30:06 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:119220 Archived-At: > From: Guilhem Bichot > 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.