From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1781 invoked by alias); 3 Jan 2008 16:52:04 -0000 Received: (qmail 1771 invoked by uid 22791); 3 Jan 2008 16:52:03 -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 16:47:10 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id E060998120; Thu, 3 Jan 2008 16:47:07 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id B28B39811F; Thu, 3 Jan 2008 16:47:07 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.68) (envelope-from ) id 1JATDm-0004EA-MK; Thu, 03 Jan 2008 11:47:06 -0500 Date: Thu, 03 Jan 2008 16:52:00 -0000 From: Daniel Jacobowitz To: Aleksandar Ristovski Cc: gdb@sourceware.org, Ryan Mansfield Subject: Re: gdb_realpath: dealing with ./ and ../ Message-ID: <20080103164706.GA15981@caradoc.them.org> Mail-Followup-To: Aleksandar Ristovski , gdb@sourceware.org, Ryan Mansfield References: <2F6320727174C448A52CEB63D85D11F40A3E@nova.ott.qnx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2F6320727174C448A52CEB63D85D11F40A3E@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/msg00010.txt.bz2 On Thu, Jan 03, 2008 at 11:33:34AM -0500, Aleksandar Ristovski wrote: > On linux, when realpath works all is fine and it will take care of the > symbolic links. However, the problem starts when paths do not really exist > and realpath fails. A simple example is my cross-compiled binary built on > windows, being debugged on linux. In this case, when realpath fails, I would > like to 'compact' or 'normalize' the path by resolving relative path > elements (and current path elements) thus forming canonical path, whithout > resolving symlinks (which can not be resolved since they do not exist). 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. Your patch added several calls of that sort. > > > When our cross-compiler generates binary, it stores relative path in > > > .debug_line section (relative to compilation dir), i.e. '..'. > > > > What's in .debug_info? Also, what version of GDB? > > > In my case: > DW_AT_name : > c:/QNXTau/eclipse/ide-4.5-workspace/testManagedCC/main.cc>~~~~~$ > DW_AT_comp_dir : > c:/QNXTau/eclipse/ide-4.5-workspace/testManagedCC/Debug>~~~~~ 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. -- Daniel Jacobowitz CodeSourcery