Emacs 24 Debugger for Former Emacs 23 Debugger Users

Emacs 24 Debugger for Former Emacs 23 Debugger Users

[Richard Wordingham]

Emacs 23 make a pleasant GUI for simple debugging of single-threaded C
programs.  I would like to be able to pleasantly debug programs in
later versions of Emacs.  My immediate target is Emacs 24.4, for am I
running that with patches to enable me to work with 'complex text' as
the text-rendering fraternity call it.  (I don't know if these patches
are in Emacs 25.)  So far, Emacs seems to give me the best terminal
window for complex text as well.  However, the Emacs 24.4 debugger
takes time to master, and I don't use it enough to learn and remember a
lot about the debugger.  I would appreciate some help.

The debugging flow when I have a good ideas as to where the bug is
coming from is simple with Emacs 23.  For example:

* Emacs 23 - Productive Experience *

emacs23 -Q& # OK, -Q cripples me.  It's just to keep Eli happy.
M-x gdb

I get prompt 'Run gdb (like this): gdb --annotate=3 cegrep'.  This
seems fine, as I am debugging program cegrep and am in the directory
containing the executable and its source code.  I hit return.  At the
end of the start-up messages I see the important message 'Reading
symbols from /home/richard/unicode/regex/cegrep...done.'; I know I have
successfully loaded the program I want to debug.

The sole frame is now visiting buffer *gud-cegrep*. 

Now I proceed to set a breakpoint just before where the program seems
to go wrong:

C-x 5 2 ; Open a new frame
C-x C-f cegrep.c ; Use the frame to visit the file with the bug.  I
have a ribbon of debugger command icons at the top of the frame.  The
windowing system gives the frame the title 'cegrep.c', which is also
reassuring.

I then use the vanilla navigation commands to scroll to where I want to
set break.  I  left click in the 'fringe' to the left of the line I want
to break to, between the text and the scroll bar on the left, and a red
dot appears.  This is a very useful way of seeing where the break points
are.

I then switch back to frame labelled *gud-cegrep* and, at the (gdb)
prompt, issue my command to start the program:

run -A1 the cegrep.c ; I know, a bit incestuous using the source code
                     ; as input data.

The *gud-cegrep* frame loses focus; focus switches to the cegrep.c
frame, and a black triangle shows that the program is at the break
point.  I then click the 'next-line' icon in the frames window.  The
program advance to the statement on the next line, which is 'break'.  I
then click the icon again.  The program advances to a line outside the
window, and the window scrolls to follow the program counter.

I now want to read a variable's value in hex, so I switch focus to the
gud-cegrep frame and enter the command print/x *optr.  The value is
displayed in the gud-cegrep frame, which continues to hold a single
window, visiting buffer *gud-cegrep*.  The frame displaying the buffer
cegrep.c remains unchanged.

All this works fine, well at least if your monitor(s) can display
several frames side by side.

* Emacs 24 - Naive Attempt. *

For this I run GNU Emacs 24.4.5 built from the tarball using the key
command 
../configure –with-x-toolkit –prefix=/opt/local

Fire it up: /opt/local/bin/emacs -Q&
M-x gdb

I get prompt 'Run gdb (like this): gdb -i=mi cegrep'.  This
seems fine, as I am debugging program cegrep and am in the directory
containing the executable and its source code.  I hit return.  At the
end of the start-up messages I see the important message 'Reading
symbols from /home/richard/unicode/regex/cegrep...done.'; I know I have
successfully loaded the program I want to debug.

C-x 5 2 ; Open a new frame
C-x C-f cegrep.c ; Use the frame to visit the file with the bug.  I
have a ribbon of debugger command icons at the top of the frame.  The
windowing system gives the frame the title 'cegrep.c', which is also
reassuring.

I then use the vanilla navigation commands to scroll to where I want to
set break.  I  left click in the 'fringe' to the left of the line I want
to break to, to the left of the text, and, as before,  a red dot
appears. (The scroll bar is on the right now, but that's probably
nothing to do with Emacs.)

I then switch back to frame labelled *gud-cegrep* and, at the (gdb)
prompt, issue my command to start the program:

run -A1 the cegrep.c

First shock - I lose half the *gud-cegrep* frame to another window
displaying cegrep.c.  Focus goes to the window displaying buffer
*gud-cegrep*.  In both windows, the black triangular pointer shows
that the program is at the break point.

I switch focus back to the cegrep.c frame, and click on the 'next line'
button, which now has both text and an icon.  That visibly advances the
program position to the next line in both windows displaying buffer
cegrep.c.  I click again, and the program position disappears out of
view in both windows.  The windows do not scroll.

Perhaps I am not supposed to control program advance from my preferred
frame.  So I go back to the gud-cegrep frame, and reissue the command

run -A1 the cegrep.c

This restores the break point and current program location to both
windows. I click next-line twice, and the small window for the source
file in the *gud-cegrep* frame scrolls to show the place of
execution. This is unpleasant. 

* Discussion and Questions *

Now, Eli Zaretski told me that the old gud-gdb interface is still
available in Emacs 24, but my experience with trying to use that was
going to be another horror story. (OK, maybe it isn't really a horror
story until I put my fist through the monitor.  I am already tensed up
when I have to resort to the debugger.)  However, I was using the
enhanced gdb interface in Emacs 23, so gud-gdb isn't what I wanted.

Now, I do know the command goto-line, so I could get used to debugging
with Emacs 24 once I could no longer maintain Emacs 23 just as a
debugger.  It is possible to scroll the large source window by copying
the line number.  It also appears that there is a "GUD, refresh" menu
command that will do the scrolling more simply.  The command's default
binding is C-x C-a C-l (is the memonic "HAL!"?), but fortunately the
command name gud-refresh is memorable.

However, is there any way to make the window scroll automatically? Even
better, to also stop the frame I am working in from losing focus.  Have
I encountered a bug?

Richard.















emacs 










The base operating system is 

Re: Emacs 24 Debugger for Former Emacs 23 Debugger Users

[Eli Zaretskii]

> Date: Thu, 11 Jun 2015 20:36:03 +0100
> From: Richard Wordingham <richard.wordingham@ntlworld.com>
> 
> Emacs 23 make a pleasant GUI for simple debugging of single-threaded C
> programs.  I would like to be able to pleasantly debug programs in
> later versions of Emacs.  My immediate target is Emacs 24.4, for am I
> running that with patches to enable me to work with 'complex text' as
> the text-rendering fraternity call it.  (I don't know if these patches
> are in Emacs 25.)  So far, Emacs seems to give me the best terminal
> window for complex text as well.  However, the Emacs 24.4 debugger
> takes time to master, and I don't use it enough to learn and remember a
> lot about the debugger.  I would appreciate some help.

I'll try, but please decide up front whether you want to continue
using the new GDB UI, or go back to the old one.  About the latter,
you say:

> Now, Eli Zaretski told me that the old gud-gdb interface is still
> available in Emacs 24, but my experience with trying to use that was
> going to be another horror story. (OK, maybe it isn't really a horror
> story until I put my fist through the monitor.  I am already tensed up
> when I have to resort to the debugger.)  However, I was using the
> enhanced gdb interface in Emacs 23, so gud-gdb isn't what I wanted.

I believe your fears of some "horror story" have no factual basis, as
you didn't actually try that, right?  I don't expect any horrors that
way for you, since the v23 style UI is unchanged, and so what you
describe as "Productive Experience" is still a few keystrokes away,
should you decide to stick to that UI.

If, OTOH, you decide to give the new UI another try, read on.

> * Emacs 24 - Naive Attempt. *
> 
> For this I run GNU Emacs 24.4.5 built from the tarball using the key
> command 
> ../configure –with-x-toolkit –prefix=/opt/local
> 
> Fire it up: /opt/local/bin/emacs -Q&
> M-x gdb
> 
> I get prompt 'Run gdb (like this): gdb -i=mi cegrep'.  This
> seems fine, as I am debugging program cegrep and am in the directory
> containing the executable and its source code.  I hit return.  At the
> end of the start-up messages I see the important message 'Reading
> symbols from /home/richard/unicode/regex/cegrep...done.'; I know I have
> successfully loaded the program I want to debug.
> 
> C-x 5 2 ; Open a new frame

Here's your first basic mistake.  The new UI doesn't want you to open
any additional frames behind its back.  It wants to display all the
information relevant to your debug session in a single frame,
preferably subdivided into several dedicated windows, or in several
dedicated frames (see below).

> C-x C-f cegrep.c ; Use the frame to visit the file with the bug.  I
> have a ribbon of debugger command icons at the top of the frame.  The
> windowing system gives the frame the title 'cegrep.c', which is also
> reassuring.
> 
> I then use the vanilla navigation commands to scroll to where I want to
> set break.  I  left click in the 'fringe' to the left of the line I want
> to break to, to the left of the text, and, as before,  a red dot
> appears. (The scroll bar is on the right now, but that's probably
> nothing to do with Emacs.)
> 
> I then switch back to frame labelled *gud-cegrep* and, at the (gdb)
> prompt, issue my command to start the program:
> 
> run -A1 the cegrep.c

Don't do any of this; it's unnecessary.  Instead, immediately after
invoking "M-x gdb" and having Emacs show you the *gud-cegrep* buffer,
issue this GDB command:

   start -A1 the cegrep.c

(Yes, "start" instead of "run".)  This will start your program with
the specified command-line arguments, and stop it at the entry to your
'main' function.  More importantly, it will also cause Emacs
automatically display the source file where 'main' is defined; I
presume that is your cegrep.c.  You can now navigate to where you want
to put breakpoints, set the breakpoints, and continue the program by
typing "continue" into the *gud-cegrep* buffer, or by clicking the
tool-bar button that says "GO".

If you want to place breakpoints in another source file, just visit it
in the same window where you have the source file that defines 'main',
go to the line where you want to place a breakpoint, and type "M-x
gud-break RET".  Or wait until that source file is the current source
file, and do it with the mouse click on the fringe.

Please note a very important issue: you will get best results with the
new UI if you always expect your current source file (the one through
whose code you are stepping) in the same window, let's call it "the
source window".  Once again, the new UI uses a _dedicated_ source
window to show your current source file.

At this point, I suggest that you maximize your frame, and then invoke
"M-x gdb-many-windows RET", or click "Gud->GDB-MI->Display Other Windows"
from the menu bar.

Alternatively, if you'd like to have each of these multiple windows in
a separate frame, use the "M-x gdb-frame-*-buffer RET" commands (you
can also do this from the "Gud->GDB-Frames" submenu of the menu bar).
In this case, you don't need to maximize the original frame, as it
will only show 2 windows: the current source and the *gud-cegrep*
buffer.

Now continue the debugging session.  Each time you step into a
function, or hit a breakpoint, the corresponding source will be
displayed in the source window, and the other windows will
automatically show the stack (a.k.a. "backtrace"), the locals, the
program's I/O (that's where you type input to the program and see its
output, if any), and all the other relevant data -- thus saving you
many commands you should have otherwise needed to invoke to access all
this information.

If you are beginning to like this new UI, consider taking a few
moments to read its description in the Emacs User manual, starting
with the node "GDB Graphical Interface".

> First shock - I lose half the *gud-cegrep* frame to another window
> displaying cegrep.c.  Focus goes to the window displaying buffer
> *gud-cegrep*.  In both windows, the black triangular pointer shows
> that the program is at the break point.
> 
> I switch focus back to the cegrep.c frame, and click on the 'next line'
> button, which now has both text and an icon.  That visibly advances the
> program position to the next line in both windows displaying buffer
> cegrep.c.  I click again, and the program position disappears out of
> view in both windows.  The windows do not scroll.
> 
> Perhaps I am not supposed to control program advance from my preferred
> frame.  So I go back to the gud-cegrep frame, and reissue the command
> 
> run -A1 the cegrep.c
> 
> This restores the break point and current program location to both
> windows. I click next-line twice, and the small window for the source
> file in the *gud-cegrep* frame scrolls to show the place of
> execution. This is unpleasant. 

These are all consequences of your attempt to fight the new UI.  It
wants to control the windows and frames where the various buffers
related to your debugging session are displayed.  By opening a new
frame with the sane *gud-cegrep* buffer behind the UI's back, you
entered a no-no land.  Don't do that.  Instead, try playing by the
UI's rules, i.e. either use its dedicated windows in a single large
frame, or open separate frames for some or all of the specialized
buffers via the commands provided by this new UI.  Then I believe you
should be all set, and your debugging experience will be much more
pleasant.

Eventually, you should decide whether or not you like this new UI
better than the old one.  (The old UI is based on a GDB facility that
the GDB developers threaten to remove in the future -- but they are
doing that for quite some time now, so it's uncertain whether this
threat is real.)

> Now, I do know the command goto-line, so I could get used to debugging
> with Emacs 24 once I could no longer maintain Emacs 23 just as a
> debugger.  It is possible to scroll the large source window by copying
> the line number.  It also appears that there is a "GUD, refresh" menu
> command that will do the scrolling more simply.  The command's default
> binding is C-x C-a C-l (is the memonic "HAL!"?), but fortunately the
> command name gud-refresh is memorable.

If you use the new UI as I described, the source window 9and all the
other windows) will scroll as you expect.  No need for scrolling them
manually, believe me.

> However, is there any way to make the window scroll automatically?

It will be, if you use the UI correctly.  (Do you really think the
Emacs developers are so stupid as not make that happen automatically?)

> Even better, to also stop the frame I am working in from losing
> focus.

See above: don't create your own frames showing buffers related to the
debug session.  Instead, use the commands provided by the new UI to
open those frames.

> Have I encountered a bug?

Arguably, no.

HTH