From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 666 invoked by alias); 14 Apr 2006 14:04:59 -0000 Received: (qmail 656 invoked by uid 22791); 14 Apr 2006 14:04:58 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Fri, 14 Apr 2006 14:04:57 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FUOun-0003nk-WC; Fri, 14 Apr 2006 10:04:50 -0400 Date: Fri, 14 Apr 2006 14:04:00 -0000 From: Daniel Jacobowitz To: Frederic RISS Cc: Jim Blandy , GDB Patches Subject: Re: [RFC] Don't lose compilation directory in Dwarf2 line-tables Message-ID: <20060414140449.GA14270@nevyn.them.org> Mail-Followup-To: Frederic RISS , Jim Blandy , GDB Patches References: <1144927446.14807.561.camel@crx549.cro.st.com> <8f2776cb0604131049i69e9b20fv78e60c023f245e56@mail.gmail.com> <1144999942.14807.721.camel@crx549.cro.st.com> <8f2776cb0604140041o63c56c2xa9113d3c4ee259d@mail.gmail.com> <1145002976.14807.744.camel@crx549.cro.st.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1145002976.14807.744.camel@crx549.cro.st.com> User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-04/txt/msg00191.txt.bz2 On Fri, Apr 14, 2006 at 10:22:56AM +0200, Frederic RISS wrote: > > When dirname is relative, I guess we lose information by concatenating > > it with comp_dir, but I don't see where we would ever use that > > information. > > I see 2 uses for that: > - differentiating identically named source files in different parts of > the source tree. One great example of that is a Linux kernel: try > something like 'find include -name cache.h' at the root. This works > for .c files because they get their relative directory in their > DW_AT_name. > - If you move your build tree (or in a networked environment, when you > access it from another mount point), then you just have to point 'dir' > at the new root, and all the files should be found. Right now, if you > have more than one include dir, you have to add themm all to the source > search path. Now, these are useful things to do. But, it's too compiler-dependant, and build system dependant, to do it this way. Consider: you are relying on the fact that line table entries are relative to the comp_dir, and that many files have the same comp_dir. Linux 2.6 does build things this way. 2.4 built from subdirectories. Coincidentally, so does GDB. For an alternative approach, see this: http://sourceware.org/ml/gdb/2006-03/msg00189.html I think that may be a better solution; Paul, are you going to post that? Please? :-) That said, I don't much care which bits get concatenated with which other bits; as you found, it doesn't seem to make a lot of difference (and I'm of the opinion that it shouldn't make a difference). Doing it your way may be most useful. But I'd like a solution to the moved source tree problem which doesn't rely on this compiler behavior. -- Daniel Jacobowitz CodeSourcery