From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Berman Newsgroups: gmane.emacs.devel Subject: Re: gdb problem Date: Sun, 15 Jun 2008 00:25:07 +0200 Message-ID: <878wx7fyd8.fsf@escher.local.home> References: <87y759j7cl.fsf@escher.local.home> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1213482340 4828 80.91.229.12 (14 Jun 2008 22:25:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 14 Jun 2008 22:25:40 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 15 00:26: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 1K7eCT-0005zb-Ng for ged-emacs-devel@m.gmane.org; Sun, 15 Jun 2008 00:26:22 +0200 Original-Received: from localhost ([127.0.0.1]:42910 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K7eBf-00069K-Ik for ged-emacs-devel@m.gmane.org; Sat, 14 Jun 2008 18:25:31 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K7eBa-00069F-Pr for emacs-devel@gnu.org; Sat, 14 Jun 2008 18:25:26 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K7eBa-000693-9q for emacs-devel@gnu.org; Sat, 14 Jun 2008 18:25:26 -0400 Original-Received: from [199.232.76.173] (port=36385 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K7eBa-000690-6t for emacs-devel@gnu.org; Sat, 14 Jun 2008 18:25:26 -0400 Original-Received: from main.gmane.org ([80.91.229.2]:57533 helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1K7eBZ-0007uN-NI for emacs-devel@gnu.org; Sat, 14 Jun 2008 18:25:26 -0400 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1K7eBT-0000MG-Nl for emacs-devel@gnu.org; Sat, 14 Jun 2008 22:25:19 +0000 Original-Received: from i5387e512.versanet.de ([83.135.229.18]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Jun 2008 22:25:19 +0000 Original-Received: from stephen.berman by i5387e512.versanet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Jun 2008 22:25:19 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 85 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: i5387e512.versanet.de User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) 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:99227 Archived-At: On Sat, 14 Jun 2008 13:33:30 +0300 Eli Zaretskii wrote: >> 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. 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