From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Stallman To: eliz@is.elta.co.il Cc: per@bothner.com, tromey@redhat.com, gdb@sources.redhat.com, emacs-hackers@gnu.org Subject: Re: Using gdb with emacs Date: Mon, 10 Sep 2001 15:50:00 -0000 Message-id: <200109102250.QAA05383@aztec.santafe.edu> References: <874rqfvl52.fsf@creche.redhat.com> <2593-Fri07Sep2001105921+0300-eliz@is.elta.co.il> <87elpid9dt.fsf@creche.redhat.com> <7458-Sat08Sep2001103423+0300-eliz@is.elta.co.il> <2561-Sun09Sep2001203900+0300-eliz@is.elta.co.il> X-SW-Source: 2001-09/msg00095.html The debug info recorded in the executable says that one of the source files is ../foo/bar/baz.c. How can GDB know that a file you are visiting, whose absolute file name is /home/user/project/foo/bar/baz.c, is that file? If the files named baz.c have full names ../foo/bar/baz.c and ../foo/lose/baz.c, GDB could figure out that /home/user/project/foo/bar/baz.c, must be the former rather than the latter. It could move up in the file names, eliminating possibilities when it sees a mismatch, and if at some point only one file name still remains undisqualified, that is the one. Because gcc, for each .o file (at least when using stabs) emits *both* the relative filename *and* the current working directory. So gdb can calculete the absolute filename. It can do that, and that may be one good thing to try; but that may not be the full solution. It is not unusual to move directories around; when that has happened, this method would fail just like now. Perhaps it should first try to recognize the absolute file name, and then, if that fails, try what I suggested above.