From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: gdb problem Date: Sat, 14 Jun 2008 13:33:30 +0300 Message-ID: References: <87y759j7cl.fsf@escher.local.home> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1213459129 5546 80.91.229.12 (14 Jun 2008 15:58:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 14 Jun 2008 15:58:49 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stephen Berman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 14 17:59:23 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1K7Y9y-0002Fi-IF for ged-emacs-devel@m.gmane.org; Sat, 14 Jun 2008 17:59:22 +0200 Original-Received: from localhost ([127.0.0.1]:53665 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K7Y9A-0004Em-6k for ged-emacs-devel@m.gmane.org; Sat, 14 Jun 2008 11:58:32 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K7Y93-0004E1-DG for emacs-devel@gnu.org; Sat, 14 Jun 2008 11:58:25 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K7Y92-0004DU-MB for emacs-devel@gnu.org; Sat, 14 Jun 2008 11:58:24 -0400 Original-Received: from [199.232.76.173] (port=47804 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K7Y92-0004DH-CR for emacs-devel@gnu.org; Sat, 14 Jun 2008 11:58:24 -0400 Original-Received: from mx20.gnu.org ([199.232.41.8]:39852) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1K7XaL-0005rA-OK for emacs-devel@gnu.org; Sat, 14 Jun 2008 11:22:33 -0400 Original-Received: from mtaout5.012.net.il ([84.95.2.13]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1K7T4g-00029q-E1 for emacs-devel@gnu.org; Sat, 14 Jun 2008 06:33:34 -0400 Original-Received: from HOME-C4E4A596F7 ([84.228.242.237]) by i_mtaout5.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0K2G00LCC8OX9DZ0@i_mtaout5.012.net.il> for emacs-devel@gnu.org; Sat, 14 Jun 2008 13:48:34 +0300 (IDT) In-reply-to: <87y759j7cl.fsf@escher.local.home> X-012-Sender: halo1@inter.net.il X-detected-kernel: by mx20.gnu.org: Solaris 9.1 X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:99178 Archived-At: > From: Stephen Berman > 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).