From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17878 invoked by alias); 8 Jan 2008 16:10:00 -0000 Received: (qmail 17868 invoked by uid 22791); 8 Jan 2008 16:09:59 -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 16:09:24 +0000 Received: by nimbus.ott.qnx.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jan 2008 11:09:21 -0500 Message-ID: <2F6320727174C448A52CEB63D85D11F40A5E@nova.ott.qnx.com> From: Aleksandar Ristovski To: dje@google.com, gdb-patches@sourceware.org Subject: RE: [RFA] patch for DW_AT_comp_dir/DW_AT_name vs .debug_line inco nsistencies Date: Tue, 08 Jan 2008 16:10: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-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-01/txt/msg00138.txt.bz2 > -----Original Message----- > From: dje@google.com [mailto:dje@google.com] > Sent: January 6, 2008 9:24 PM > To: gdb-patches@sourceware.org > Cc: Aleksandar Ristovski > Subject: RE: [RFA] patch for DW_AT_comp_dir/DW_AT_name vs .debug_line > inconsistencies > > How about this? > By looking at the code, looks good to me, but I can also see good points in Joel's post: http://sourceware.org/ml/gdb/2008-01/msg00048.html Whichever approach (fix in start_subfile or dwarf2read.c) I think the following is common: About normalize_path: I am really missing how would symlink spoil anything. I did a few tests: a) No symlinks: I make my comp_dir a working directory. Then I compile something like: gcc ../main.cc -o main.o debug info is: 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$ b) Symlinks involved: b1) Then I tried to make a symlink to another location: ln -s /tmp /foo/bar/obj Make /foo/bar/obj my work dir and try: gcc ../main.cc It fails to find it (and rightfully so). The only way I could build it is by using the absolute names. gcc -c -g /foo/bar/main.cc -o main.o now DW_AT_comp_dir is not specified and all paths are absolute (so no problems there). My conclusion is that whatever gcc stores in debug info (related to paths) should be taken as a snapshot of what it saw and we should not worry about symlinks at all... if you can, please, give me a good example where normalize_path would break things due to symlinks? Thanks Aleksandar