From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5387 invoked by alias); 8 Jan 2008 16:46:12 -0000 Received: (qmail 5374 invoked by uid 22791); 8 Jan 2008 16:46:12 -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; Tue, 08 Jan 2008 16:45:47 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 83A4498216; Tue, 8 Jan 2008 16:45:45 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 6945898022; Tue, 8 Jan 2008 16:45:45 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.68) (envelope-from ) id 1JCHaC-0006pJ-Gz; Tue, 08 Jan 2008 11:45:44 -0500 Date: Tue, 08 Jan 2008 16:46:00 -0000 From: Daniel Jacobowitz 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 Message-ID: <20080108164544.GA25831@caradoc.them.org> Mail-Followup-To: Aleksandar Ristovski , dje@google.com, gdb-patches@sourceware.org References: <2F6320727174C448A52CEB63D85D11F40A62@nova.ott.qnx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2F6320727174C448A52CEB63D85D11F40A62@nova.ott.qnx.com> User-Agent: Mutt/1.5.17 (2007-12-11) 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/msg00143.txt.bz2 On Tue, Jan 08, 2008 at 11:33:28AM -0500, Aleksandar Ristovski wrote: > > > > -----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. The above line table will never provoke the bug that we have been discussing. You have "/foo/bar/obj" as the compilation directory. In .debug_info you have "../main.cc" appended to that. In .debug_line you have ".." and "main.c" appended to it. GDB will get the same result from both. Your original example had "c:/QNXTau/eclipse/ide-4.5-workspace/testManagedCC/main.cc" for the name, "c:/QNXTau/eclipse/ide-4.5-workspace/testManagedCC/Debug" for the compilation directory, and ".." and "main.c" in .debug_line. So .debug_info said "c:/QNXTau/eclipse/ide-4.5-workspace/testManagedCC/main.cc" and .debug_line said "c:/QNXTau/eclipse/ide-4.5-workspace/testManagedCC/Debug/../main.cc". If there had been a symlink involved, those would have been different files; they are different paths. The compiler should never do this. I still say that this is a bug in the compiler. Does a more recent version of GCC still do so? GCC 3.3.5 predates an official FSF port to native Windows. -- Daniel Jacobowitz CodeSourcery