From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23249 invoked by alias); 3 Jan 2008 17:13:54 -0000 Received: (qmail 23239 invoked by uid 22791); 3 Jan 2008 17:13:52 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 03 Jan 2008 17:09:12 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id C62FA98120; Thu, 3 Jan 2008 17:08:47 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id A7B199811F; Thu, 3 Jan 2008 17:08:47 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.68) (envelope-from ) id 1JATYk-0004Xe-91; Thu, 03 Jan 2008 12:08:46 -0500 Date: Thu, 03 Jan 2008 17:13:00 -0000 From: Daniel Jacobowitz To: Aleksandar Ristovski Cc: gdb@sourceware.org, Ryan Mansfield Subject: Re: gdb_realpath: dealing with ./ and ../ Message-ID: <20080103170846.GA17263@caradoc.them.org> Mail-Followup-To: Aleksandar Ristovski , gdb@sourceware.org, Ryan Mansfield References: <2F6320727174C448A52CEB63D85D11F40A3F@nova.ott.qnx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2F6320727174C448A52CEB63D85D11F40A3F@nova.ott.qnx.com> User-Agent: Mutt/1.5.17 (2007-12-11) 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/msg00012.txt.bz2 On Thu, Jan 03, 2008 at 12:01:16PM -0500, Aleksandar Ristovski wrote: > > We should not call realpath on files which are not known to exist on > > the system running GDB. If we do that somewhere, it's a bug. > > I am not sure it is a bug. At the time of gdb_realpath call, gdb can not > know whether the path exists or not, it takes the path information from > debug info. Second, it is perfectly normal situation where sources are not > available at all, and paths mentioned in debug_info do not physically exist > on the system. Paths from debug info are adjusted before we treat them as local paths. e.g. set substitute-path. > > Well, that's why. If DW_AT_name was main.cc, things would have > > worked. That's what GCC generates for me. You have debug info which > > refers to the same file using two different pathnames. > > > > Perhaps we can forcibly associate the compilation unit with the first > > entry in the file name table, if they have the same basename and no > > other file in the line table matches the CU better. > > Would this not introduce a bit of guessing? Consider a case where there are > several files with the same basename but different paths (possibly specified > using relative path elements, i.e. different pathnames like in my case). In > this case none of the files with the same base name would perfectly fit and > picking the first one will likely not give the correct answer. It's a guess, but a good one. 99.9% of the time, a C file does not include another C file with the same basename. If the compiler is going to generate debug info which refers to the same file by two different names, I don't see what else we can do. 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. -- Daniel Jacobowitz CodeSourcery