From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31735 invoked by alias); 8 Jan 2008 16:34:12 -0000 Received: (qmail 31688 invoked by uid 22791); 8 Jan 2008 16:33:57 -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:33:30 +0000 Received: by nimbus.ott.qnx.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jan 2008 11:33:26 -0500 Message-ID: <2F6320727174C448A52CEB63D85D11F40A62@nova.ott.qnx.com> From: Aleksandar Ristovski To: Daniel Jacobowitz Cc: 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:34: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/msg00142.txt.bz2 > -----Original Message----- > From: Daniel Jacobowitz [mailto:drow@false.org] > Sent: January 8, 2008 11:19 AM > To: Aleksandar Ristovski > Cc: dje@google.com; gdb-patches@sourceware.org > Subject: Re: [RFA] patch for DW_AT_comp_dir/DW_AT_name vs .debug_line inco > nsistencies > > On Tue, Jan 08, 2008 at 11:09:18AM -0500, Aleksandar Ristovski wrote: > > 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). > > No, try: > > mkdir -p /foo/bar/real-obj/obj > touch /foo/bar/real-obj/main.c > rm /foo/bar/obj > ln -s /foo/bar/real-obj/obj /foo/bar/obj > cd /foo/bar/obj > gcc ../main.c > > The path "/foo/bar/obj/../main.c" is valid. The path > "/foo/bar/main.c" is not. I recreated your case. My physical path: My compiler generated this: DW_AT_name : ../main.cc>~~~~$ DW_AT_comp_dir : /foo/bar/obj>~~~~ (note how it stored symlink in comp_dir) The Directory Table:$ ..$ $ The File Name Table:$ Entry>Dir>~~~~Time>~~~Size>~~~Name$ 1>~~~~1>~~~~~~0>~~~~~~0>~~~~~~main.cc$ I still don't see the issue. The mere fact that my /foo/bar/main.cc does not really live there but rather in /foo/bar/real-obj doesn't make any difference for resolving debug_info and debug_line information. Gcc thought it was there, that should be good enough for gdb. > > I think we should not implement this unless we have a real-world > example where it would be necessary. It would require a version of > the compiler which outputs different paths in .debug_info and > .debug_line for the same file (which is a bug in the compiler, in my > opinion!), a Makefile using ".." to find source files, and a source > file including another file with the same basename. The above is a real-world example. Note that we are not trying to solve issue of the same file stored by two different paths in debug_info and debug_line (that indeed would be a gcc bug) but rather to resolve the issue of the same file stored with the same path spelled differently. Thanks, Aleksandar QNX Software Systems