GNU bug report logs - #12113
24.0.96; Incorrect echoing of gdb output

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 12113 in the body.
You can then email your comments to 12113 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "William M. (Mike) Miller" <william.m.miller <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.96; Incorrect echoing of gdb output
Date: Wed, 1 Aug 2012 07:38:20 -0400

This bug report will be sent to the Bug-GNU-Emacs mailing list
and the GNU bug tracker at debbugs.gnu.org.  Please check that
the From: line contains a valid email address.  After a delay of up
to one day, you should receive an acknowledgement at that address.

Please write in English if possible, as the Emacs maintainers
usually do not have translators for other languages.

Please describe exactly what actions triggered the bug, and
the precise symptoms of the bug.  If you can, give a recipe
starting from `emacs -Q':

When I run M-x gdb and debug a program, some gdb output that should
appear is suppressed, and some gdb output that should be suppressed is
echoed.  The version of gdb I am using is

    GNU gdb (GDB) 7.3.50.20111026-cvs (cygwin-special)

and I am using gdb-many-windows mode.

In particular, if I type "next" in the gud interaction buffer, the
source line of the execution point is echoed in the buffer, just as it
would be if I were using gdb in an xterm outside of emacs.  It is
correctly suppressed if I use the graphical "next" button at the top of
the window.

Conversely, if I use the graphical buttons for "run", "continue", or
"step", the gdb output showing the function name and parameter values is
not echoed in the gud interaction buffer; it does appear if I type those
commands instead of using the graphical buttons.

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
/usr/share/emacs/24.0.96/etc/DEBUG.


In GNU Emacs 24.0.96.1 (i686-pc-cygwin, GTK+ Version 2.24.10)
 of 2012-05-16 on moufang
Windowing system distributor `The Cygwin/X Project', version 11.0.11203000
Configured using:
 `configure
 '--srcdir=/home/kbrown/src/cygemacs/emacs-24.0.96-2/src/emacs-24.0.96'
 '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin'
 '--sbindir=/usr/sbin' '--libexecdir=/usr/lib' '--datadir=/usr/share'
 '--localstatedir=/var' '--sysconfdir=/etc' '--datarootdir=/usr/share'
 '--docdir=/usr/share/doc/emacs' '-C' '--without-gsettings'
 '--without-gconf' 'CC=gcc' 'CFLAGS=-g -O2 -pipe '
 'LDFLAGS=-L/usr/lib/ncursesw' 'LIBS='
 'CPPFLAGS=-I/usr/include/ncursesw''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  show-paren-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
M-x r e p o r t - g n u <backspace> <backspace> <backspace>
e m a c s - b u g <return>

Recent messages:
Loading paren...done
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail regexp-opt rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils paren cus-start cus-load
time-date tooltip ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd
tool-bar dnd fontset image fringe lisp-mode register page menu-bar
rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax
facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak
czech european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer loaddefs button faces
cus-face files text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget hashtable-print-readable backquote
make-network-process dbusbind dynamic-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty emacs)


-- 
William M. (Mike) Miller | Edison Design Group
william.m.miller <at> gmail.com

Message #8 received at 12113 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "William M. (Mike) Miller" <william.m.miller <at> gmail.com>
Cc: 12113 <at> debbugs.gnu.org
Subject: Re: bug#12113: 24.0.96; Incorrect echoing of gdb output
Date: Wed, 01 Aug 2012 19:46:25 +0300

> Date: Wed, 1 Aug 2012 07:38:20 -0400
> From: "William M. (Mike) Miller" <william.m.miller <at> gmail.com>
> 
> In particular, if I type "next" in the gud interaction buffer, the
> source line of the execution point is echoed in the buffer, just as it
> would be if I were using gdb in an xterm outside of emacs.  It is
> correctly suppressed if I use the graphical "next" button at the top of
> the window.
> 
> Conversely, if I use the graphical buttons for "run", "continue", or
> "step", the gdb output showing the function name and parameter values is
> not echoed in the gud interaction buffer; it does appear if I type those
> commands instead of using the graphical buttons.

I think this is expected: the MI interpreter used by Emacs causes
different outputs to be emitted by GDB than when you use the
equivalent CLI interpreter commands.

The information you see when you type GDB CLI commands into the gud
buffer is shown in the "many windows" when you use the GUI controls.
So no information is lost.

Can you tell why the current behavior is a problem?

Message #11 received at 12113 <at> debbugs.gnu.org (full text, mbox):

From: "William M. (Mike) Miller" <william.m.miller <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 12113 <at> debbugs.gnu.org
Subject: Re: bug#12113: 24.0.96; Incorrect echoing of gdb output
Date: Wed, 1 Aug 2012 13:30:26 -0400

On Wed, Aug 1, 2012 at 12:46 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> Date: Wed, 1 Aug 2012 07:38:20 -0400
>> From: "William M. (Mike) Miller" <william.m.miller <at> gmail.com>
>>
>> In particular, if I type "next" in the gud interaction buffer, the
>> source line of the execution point is echoed in the buffer, just as it
>> would be if I were using gdb in an xterm outside of emacs.  It is
>> correctly suppressed if I use the graphical "next" button at the top of
>> the window.
>>
>> Conversely, if I use the graphical buttons for "run", "continue", or
>> "step", the gdb output showing the function name and parameter values is
>> not echoed in the gud interaction buffer; it does appear if I type those
>> commands instead of using the graphical buttons.
>
> I think this is expected: the MI interpreter used by Emacs causes
> different outputs to be emitted by GDB than when you use the
> equivalent CLI interpreter commands.
>
> The information you see when you type GDB CLI commands into the gud
> buffer is shown in the "many windows" when you use the GUI controls.
> So no information is lost.
>
> Can you tell why the current behavior is a problem?

Echoing the source line when I type "next" in the gud interaction
buffer is more of an annoyance than a "problem" -- it fills up the
buffer with unnecessary text, and if I've printed the value of some
expressions, it causes them to scroll offscreen more rapidly than
they otherwise would.  However, I'm content with just always
using the graphical button for "next" instead of typing it once and
using Enter repeatedly to step through the code, as I had been
doing in previous versions (with --annotate).

The real problem is suppressing the output of the parameter
values when hitting a breakpoint after running or continuing via
a graphical button, or when stepping into a function.  Those values
do not appear in the "locals" buffer, so to see them I either have
to print them manually or, if it's a breakpoint, I have to set an
action list to display them.  (Actually, that's not quite true; I note,
interestingly enough, that the "up" and "down" stack navigation
buttons _do_ display the summary line with the parameter values,
so I could just do an "up" then "down" to see the values of the
parameters in the current function -- but that displays the values
for frame 1 as well as frame 0, so it's less than ideal, but at least
it's shorter than typing the requisite "print" commands.)

-- 
William M. (Mike) Miller | Edison Design Group
william.m.miller <at> gmail.com

Message #14 received at 12113 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "William M. (Mike) Miller" <william.m.miller <at> gmail.com>
Cc: 12113 <at> debbugs.gnu.org
Subject: Re: bug#12113: 24.0.96; Incorrect echoing of gdb output
Date: Wed, 01 Aug 2012 23:27:04 +0300

> Date: Wed, 1 Aug 2012 13:30:26 -0400
> From: "William M. (Mike) Miller" <william.m.miller <at> gmail.com>
> Cc: 12113 <at> debbugs.gnu.org
> 
> The real problem is suppressing the output of the parameter
> values when hitting a breakpoint after running or continuing via
> a graphical button, or when stepping into a function.  Those values
> do not appear in the "locals" buffer, so to see them I either have
> to print them manually or, if it's a breakpoint, I have to set an
> action list to display them.

In the Breakpoints window, if you click the "Threads" button on the
window's header line, don't you see the arguments of the current
function's call?

> Actually, that's not quite true; I note,
> interestingly enough, that the "up" and "down" stack navigation
> buttons _do_ display the summary line with the parameter values,

That's sheer luck: stack navigation buttons work by issuing CLI
commands, not MI commands, to which GDB responds by showing the call
argument.

Message #19 received at 12113-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 12113-done <at> debbugs.gnu.org,
 "William M. \(Mike\) Miller" <william.m.miller <at> gmail.com>
Subject: Re: bug#12113: 24.0.96; Incorrect echoing of gdb output
Date: Thu, 31 Oct 2019 00:36:29 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Date: Wed, 1 Aug 2012 13:30:26 -0400
>> From: "William M. (Mike) Miller" <william.m.miller <at> gmail.com>
>> Cc: 12113 <at> debbugs.gnu.org
>> 
>> The real problem is suppressing the output of the parameter
>> values when hitting a breakpoint after running or continuing via
>> a graphical button, or when stepping into a function.  Those values
>> do not appear in the "locals" buffer, so to see them I either have
>> to print them manually or, if it's a breakpoint, I have to set an
>> action list to display them.
>
> In the Breakpoints window, if you click the "Threads" button on the
> window's header line, don't you see the arguments of the current
> function's call?

More information was requested, but none was given within 7 years, so
I'm closing this bug.  If this is still an issue, please reopen the bug
report.

Best regards,
Stefan Kangas

Previous Next

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