From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31414 invoked by alias); 8 Jan 2008 19:21:11 -0000 Received: (qmail 31400 invoked by uid 22791); 8 Jan 2008 19:21:11 -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; Tue, 08 Jan 2008 19:20:36 +0000 Received: by nimbus.ott.qnx.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jan 2008 14:20:31 -0500 Message-ID: <2F6320727174C448A52CEB63D85D11F40A6A@nova.ott.qnx.com> From: Aleksandar Ristovski To: Mark Kettenis Cc: brobecker@adacore.com, dje@google.com, gdb@sourceware.org, Ryan Mansfield Subject: RE: gdb_realpath: dealing with ./ and ../ Date: Tue, 08 Jan 2008 19:21: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/msg00054.txt.bz2 > > > If we can confirm for sure that "normalize_path" is safe, I think the > idea > > is good (please read my comment about normalize_path here: > > http://sourceware.org/ml/gdb-patches/2008-01/msg00138.html) > > > > Example > > DW_AT_name=../main.cc > > DW_AT_comp_dir=/foo/bar/obj > > The Directory Table: > > .. > > The File Name Table:$ > > Entry>Dir>~~~~Time>~~~Size>~~~Name$ > > 1>~~~~1>~~~~~~0>~~~~~~0>~~~~~~main.cc$ > > > > Now we get rid of the comp_dir information (this is what effectively > > happens): > > > > NAME=main.cc > > DIR=/foo/bar > > > > And there is no info about /foo/bar/obj. > > > > > > I would think that this is safe. > > Unfortunately it isn't. If /foo/bar/obj is a symlink to /bar/foo/obj, > then ../main.cc actually refers to /bar/foo/main.cc, and not > /foo/bar/main.cc. So just "normalizing" names is defenitely unsafe. > > The big question here is, whether a compiler will actually set > DW_AT_comp_dir to /foo/bar/obj in that case. One can argue that the > compilation directory really is /bar/foo/obj in that case and that > DW_AT_comp_dir should be set to /bar/foo/obj. Therefore, this concludes this trail of thoughts and this topic should probably be considered closed. Any further discussion related to the issue mentioned at the beginning of the topic should be continued here: http://sourceware.org/ml/gdb-patches/2008-01/msg00148.html