From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20566 invoked by alias); 4 Jan 2008 22:09:51 -0000 Received: (qmail 20558 invoked by uid 22791); 4 Jan 2008 22:09:50 -0000 X-Spam-Check-By: sourceware.org Received: from qnxmail.qnx.com (HELO nimbus.ott.qnx.com) (209.226.137.76) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 04 Jan 2008 22:09:16 +0000 Received: by nimbus.ott.qnx.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jan 2008 17:09:13 -0500 Message-ID: <2F6320727174C448A52CEB63D85D11F40A55@nova.ott.qnx.com> From: Aleksandar Ristovski To: Daniel Jacobowitz , Doug Evans Cc: gdb@sourceware.org, Ryan Mansfield Subject: RE: gdb_realpath: dealing with ./ and ../ Date: Fri, 04 Jan 2008 22:09:00 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-01/txt/msg00029.txt.bz2 > > On Fri, Jan 04, 2008 at 01:39:51PM -0800, Doug Evans wrote: > > The use of #line in the testcases in the appended patch is > > questionable, but as a data point the testcases fail without the patch > > and pass with the patch. These versions of the testcases have been > > amended to use substitute-path. @Doug: Without trying-out your patch, by just looking at it, I don't think it solves testcase number 2 from my previous post: http://sourceware.org/ml/gdb/2008-01/msg00024.html This test case was my initial issue I wanted to solve, and then other issues come up. So my original problem was not related to using substitute-path (the inconsistency of substitute-path should probably be discussed in a separate thread), but in having two pathnames for the same physical path. One comes from DW_AT_name And is a full file name, e.g. /foo/bar/main.cc Second is constructed from .debug_line information, by concatenating directory (which is "..") and file name ("main.cc") giving "../main.cc" which is then appended to DW_AT_comp_dir resulting in: /foo/bar/Debug/../main.cc Now in start_subfile we are comparing: /foo/bar/main.cc for which subfile structure had been constructed already and /foo/bar/Debug/../main.cc Which should yield to finding the already constructed structure, but since FILENAME_CMP does fairly simple file comparison, it fails to match it and then goes on to create new subfile structure which is wrong. After that, another lookup is done and the first subfile is found (using /foo/bar/main.cc) but due to no line information associated with it, gdb fails to find info about that line and displays the error message to the user (something like "no line NN in main.cc"). > > This happens during symbol reading, right? That means substitute-path > has to be set before GDB loads any files; another reason why I don't > think it is appropriate to use it while building symtabs. > > I'll look at the rest of this thread later. Part of the solution to the testcase 2 is to add opposite case (we are checking only IS_ABSOLUTE_PATH (name)... but we do not cover the case where NAME is relative (and existing subfile->name is absolute, which is exactly my case). Maybe the other part of the solution to testcase 2 should really be in rewriting FILENAME_CMP to try other alternatives if simple comparison fails. It could remove '..' path elements and it would be safe if we are dealing with paths coming from the binary. > > -- > Daniel Jacobowitz > CodeSourcery