From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29375 invoked by alias); 3 Jan 2008 16:39:08 -0000 Received: (qmail 29364 invoked by uid 22791); 3 Jan 2008 16:39:08 -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 16:33:48 +0000 Received: by nimbus.ott.qnx.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jan 2008 11:33:46 -0500 Message-ID: <2F6320727174C448A52CEB63D85D11F40A3E@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 16:39: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/msg00009.txt.bz2 > -----Original Message----- > From: Daniel Jacobowitz [mailto:drow@false.org] > Sent: January 3, 2008 10:56 AM > To: Aleksandar Ristovski > Cc: gdb@sourceware.org; Ryan Mansfield > Subject: Re: gdb_realpath: dealing with ./ and ../ > > On Thu, Jan 03, 2008 at 10:20:19AM -0500, Aleksandar Ristovski wrote: > > Hello, > > > > First a question, to give an idea what I am talking about and then > detailed > > explanation. > > > > Question: Should gdb_realpath deal with './' and '../' path elements and > > compact them along with 'canonicalization' it already does? > > The problem with this idea is that removing ../ is not reliably > correct. On Unix, symlinks allow foo/../bar and bar to be different 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). Additional problem is on windows, where realpath doesn't work and gdb_realpath usually simply returns the input parameter. (my proposed patch doesn't solve this... it is not complete yet). > directories. We should only canonicalize paths to local files, not to > files mentioned in debug information. > > gdb_realpath shouldn't need any changes to handle ..; it works from > the local filesystem and constructs a real canonical path. I see that > you're on Windows. gdb_realpath may not handle Windows correctly; > libiberty's lrealpath does and I don't know why we still have both. I don't think lrealpath would work in case the real path doesn't exist. > > > 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>~~~~~ GDB version 6.7. > > I have: > > <0><154>: Abbrev Number: 1 (DW_TAG_compile_unit) > <189> DW_AT_name : ../main.c > <193> DW_AT_comp_dir : /home/drow/z/baz > > The Directory Table: > .. > > The File Name Table: > Entry Dir Time Size Name > 1 1 0 0 main.c > > So everything constructs the same /home/drow/z/baz/../main.c. > > -- > Daniel Jacobowitz > CodeSourcery