gdb problem

gdb problem

[Stephen Berman]

I've hit a problem using gdb while debugging emacs, and though it may
well be user error and not related to Emacs at all, I hope I can get
some help here.  I wanted to follow the execution of Fdisplay_buffer in
window.c (as it existed prior to its recent reimplementation in lisp).
I have an older Emacs source tree under
/Users/steve/lib/emacs-cvs-pre-unicode/src and with this as the working
directory I started gdb; here's the session:

(wd now: /Users/steve/lib/emacs-cvs-pre-unicode/src)
steve@escher:/Users/steve/lib/emacs-cvs-pre-unicode/src> gdb ./emacs
GNU gdb 6.6.50.20070726-cvs
Copyright (C) 2007 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i586-suse-linux"...
Using host libthread_db library "/lib/libthread_db.so.1".
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
DISPLAY = :0
TERM = xterm-256color
Breakpoint 1 at 0x8109336: file emacs.c, line 432.
Breakpoint 2 at 0x81233c9: file sysdep.c, line 1332.
(gdb) r -Q
Starting program: /Users/steve/lib/emacs-cvs-pre-unicode/src/emacs -Q
[Thread debugging using libthread_db enabled]
[New Thread 0xb6e928d0 (LWP 12617)]

Program received signal SIGTSTP, Stopped (user).
[Switching to Thread 0xb6e928d0 (LWP 12617)]
0xffffe410 in __kernel_vsyscall ()
(gdb) br /Users/steve/lib/emacs-cvs-pre-unicode/src/window.c:3840
Internal: readin window.c pst for `/Users/steve/lib/emacs-cvs-pre-unicode/src/window.c' found when no symtab found.
(gdb) br window.c:3840
Breakpoint 3 at 0x8099956: file window.c, line 3840.
(gdb) c
Continuing.

Breakpoint 3, Fdisplay_buffer (buffer=137869892, not_this_window=137636041, frame=137636041)
    at window.c:3840
warning: Source file is more recent than executable.
3840      p->next = o->next;


First, I do not understand the gdb response when I tried to set a
breakpoint using an absolute path, but it evidently failed to set the
breakpoint.  Then I just used the file name and that did set the
breakpoint, and when it hit the breakpoint, gdb said it was in
Fdisplay_buffer, which is what I wanted, so this seemed to be ok.  But
the next two lines, the last two listed above, are strange: the warning
that the source file is more recent than the executable, and the content
of the line at the breakpoint.  In fact, this line is from window.c in
the directory /Users/steve/cvsroot/emacs/src, which is my source
directory of the Emacs CVS trunk (which does not contain Fdisplay_buffer
any more).

What happened here?  And what do I have to do to be able to step through
Fdisplay_buffer in the older source code?  I'd be grateful for any help.

Steve Berman

Re: gdb problem

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Date: Sat, 14 Jun 2008 00:30:34 +0200
> 
> (gdb) br /Users/steve/lib/emacs-cvs-pre-unicode/src/window.c:3840
> Internal: readin window.c pst for `/Users/steve/lib/emacs-cvs-pre-unicode/src/window.c' found when no symtab found.
> (gdb) br window.c:3840
> Breakpoint 3 at 0x8099956: file window.c, line 3840.
> (gdb) c
> Continuing.
> 
> Breakpoint 3, Fdisplay_buffer (buffer=137869892, not_this_window=137636041, frame=137636041)
>     at window.c:3840
> warning: Source file is more recent than executable.
> 3840      p->next = o->next;
> 
> 
> First, I do not understand the gdb response when I tried to set a
> breakpoint using an absolute path, but it evidently failed to set the
> breakpoint.  Then I just used the file name and that did set the
> breakpoint, and when it hit the breakpoint, gdb said it was in
> Fdisplay_buffer, which is what I wanted, so this seemed to be ok.  But
> the next two lines, the last two listed above, are strange: the warning
> that the source file is more recent than the executable, and the content
> of the line at the breakpoint.  In fact, this line is from window.c in
> the directory /Users/steve/cvsroot/emacs/src, which is my source
> directory of the Emacs CVS trunk (which does not contain Fdisplay_buffer
> any more).
> 
> What happened here?

There's something I'd like you to explain first.  If, as you say, the
Emacs binary you were debugging was produced from the sources in the
same /Users/steve/lib/emacs-cvs-pre-unicode/ tree, then why did you
use an absolute file name to set a breakpoint in the first place?
That's a highly unusual thing to do on systems where the source file
names and the directories they live in are recorded in the executable's
debug info.

More to the point, my crystal ball says that you compiled that Emacs
binary in the /Users/steve/cvsroot/emacs/ tree, and then moved it,
together with the sources, into /Users/steve/lib/emacs-cvs-pre-unicode/.
As I say above, the original directories are recorded in the debug
info which GDB reads and uses, so it tries to access the source files
which were since updated.

To verify that my guess is correct, type "info sources" in GDB, and
see where it thinks your source files live.

If my guess is correct, then the following command should tell GDB to
try the sources in /Users/steve/lib/emacs-cvs-pre-unicode/src first:

  (gdb) dir /Users/steve/lib/emacs-cvs-pre-unicode/src

(you should probably do the same for the lwlib directory).

GDB has a more powerful feature for this kind of situations: the "set
substitute-path" command.  If the above doesn't help, read about that
command in the GDB manual, and set up your substitution rules to point
GDB at the /Users/steve/lib/emacs-cvs-pre-unicode/ tree.

Alternatively, just rebuilding Emacs in the emacs-cvs-pre-unicode tree
should resolve all these problems (again, if my guess about the root
cause is correct).

Re: gdb problem

[Stephen Berman]

On Sat, 14 Jun 2008 13:33:30 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Date: Sat, 14 Jun 2008 00:30:34 +0200
>> 
>> (gdb) br /Users/steve/lib/emacs-cvs-pre-unicode/src/window.c:3840
>> Internal: readin window.c pst for `/Users/steve/lib/emacs-cvs-pre-unicode/src/window.c' found when no symtab found.
>> (gdb) br window.c:3840
>> Breakpoint 3 at 0x8099956: file window.c, line 3840.
>> (gdb) c
>> Continuing.
>> 
>> Breakpoint 3, Fdisplay_buffer (buffer=137869892, not_this_window=137636041, frame=137636041)
>>     at window.c:3840
>> warning: Source file is more recent than executable.
>> 3840      p->next = o->next;
>> 
>> 
>> First, I do not understand the gdb response when I tried to set a
>> breakpoint using an absolute path, but it evidently failed to set the
>> breakpoint.  Then I just used the file name and that did set the
>> breakpoint, and when it hit the breakpoint, gdb said it was in
>> Fdisplay_buffer, which is what I wanted, so this seemed to be ok.  But
>> the next two lines, the last two listed above, are strange: the warning
>> that the source file is more recent than the executable, and the content
>> of the line at the breakpoint.  In fact, this line is from window.c in
>> the directory /Users/steve/cvsroot/emacs/src, which is my source
>> directory of the Emacs CVS trunk (which does not contain Fdisplay_buffer
>> any more).
>> 
>> What happened here?
>
> There's something I'd like you to explain first.  If, as you say, the
> Emacs binary you were debugging was produced from the sources in the
> same /Users/steve/lib/emacs-cvs-pre-unicode/ tree, then why did you
> use an absolute file name to set a breakpoint in the first place?
> That's a highly unusual thing to do on systems where the source file
> names and the directories they live in are recorded in the executable's
> debug info.

Actually, in my first attempt to debug Fdisplay_buffer I did just type
"br window.c:3840" and got the same result as above.  Since that was
obviously not what I expected, in my ignorance of gdb I thought it
wouldn't hurt to try using an absolute file name.  In the post I
included both for the sake of completeness.

> More to the point, my crystal ball says that you compiled that Emacs
> binary in the /Users/steve/cvsroot/emacs/ tree, and then moved it,
> together with the sources, into /Users/steve/lib/emacs-cvs-pre-unicode/.
> As I say above, the original directories are recorded in the debug
> info which GDB reads and uses, so it tries to access the source files
> which were since updated.

Your crystal ball is crystal clear; would you like to ask it who's going
to win the European football championship or the US presidential
election?

> To verify that my guess is correct, type "info sources" in GDB, and
> see where it thinks your source files live.

It indeed shows source in both of the directories.

> If my guess is correct, then the following command should tell GDB to
> try the sources in /Users/steve/lib/emacs-cvs-pre-unicode/src first:
>
>   (gdb) dir /Users/steve/lib/emacs-cvs-pre-unicode/src
>
> (you should probably do the same for the lwlib directory).
>
> GDB has a more powerful feature for this kind of situations: the "set
> substitute-path" command.  If the above doesn't help, read about that
> command in the GDB manual, and set up your substitution rules to point
> GDB at the /Users/steve/lib/emacs-cvs-pre-unicode/ tree.

Thanks for the pointer; before posting I did briefly look at the table
of contents of the gdb manual but didn't see anything recognizably
relevant.

> Alternatively, just rebuilding Emacs in the emacs-cvs-pre-unicode tree
> should resolve all these problems (again, if my guess about the root
> cause is correct).

Thanks for the help and the useful information.

Steve Berman