From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13224 invoked by alias); 3 Jan 2008 18:30:44 -0000 Received: (qmail 13215 invoked by uid 22791); 3 Jan 2008 18:30:44 -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; Thu, 03 Jan 2008 18:26:32 +0000 Received: by nimbus.ott.qnx.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jan 2008 13:26:06 -0500 Message-ID: <2F6320727174C448A52CEB63D85D11F40A41@nova.ott.qnx.com> From: Aleksandar Ristovski To: Daniel Jacobowitz Cc: gdb@sourceware.org, Ryan Mansfield Subject: RE: gdb_realpath: dealing with ./ and ../ Date: Thu, 03 Jan 2008 18:30: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/msg00013.txt.bz2 > An alternative would be to do some canonicalization - not > gdb_realpath, which accesses the filesystem, but just string > manipulation - on the subfile names iff nothing matches the main > file. You could remove the ".." there. Allright, I will try with the alternative. I see two problems: 1. Problem one - relative NAME and absolute subfile->name case not covered: In function start_subfile (buildsym.c:approx 554) we completely miss one case: when NAME is relative path but subfile->name is absolute. I put some instrumentation to illustrate this problem. The list below says what is happening and specifies name, directory: start_subfile: c:/testManagedCC/main.cc, c:/testManagedCC/Debug creating subfile: c:/testManagedCC/main.cc, c:/testManagedCC/Debug start_subfile: ../main.cc, c:/testManagedCC/Debug comparing: c:/testManagedCC/main.cc, ../main.cc creating subfile: ../main.cc, c:/testManagedCC/Debug start_subfile: ../main.cc, c:/testManagedCC/Debug comparing: ../main.cc, ../main.cc Then it goes on to compare ../main.cc for each line in linetable. Note that we created two subfiles for physically one file. 2. Problem two - one physical file is specified with two pathnames. This is the case I was talking about. To fix it, I would try a combination of guessing/normalizing, by inserting code for "second-best" match using normalized path (in the same loop) if FILENAME_CMP fails to match and then if no perfect match is found, use the second-best match. Not sure what happens if there are more than one second-best matches (you say it's going to be very rare)... probably at least issue a warning and behave as if no match was found? Or resort to getting the first/last second-best match? On a second thought, if we go with the second-best match we will never get into a situation where two created subfile-s give more two second-best matches... it will always be either perfect match or the second-best... this should work. Comments?