Re: gdb problem

[Eli Zaretskii]

> From: Stephen Berman <address@hidden>
> 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).