From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27877 invoked by alias); 14 Apr 2006 14:51:46 -0000 Received: (qmail 27869 invoked by uid 22791); 14 Apr 2006 14:51:45 -0000 X-Spam-Check-By: sourceware.org Received: from lon-del-01.spheriq.net (HELO lon-del-01.spheriq.net) (195.46.50.97) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 14 Apr 2006 14:51:40 +0000 Received: from lon-out-01.spheriq.net ([195.46.50.129]) by lon-del-01.spheriq.net with ESMTP id k3EEpb7k012658 for ; Fri, 14 Apr 2006 14:51:37 GMT Received: from lon-cus-02.spheriq.net (lon-cus-02.spheriq.net [195.46.50.38]) by lon-out-01.spheriq.net with ESMTP id k3EEpar1006905 for ; Fri, 14 Apr 2006 14:51:37 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by lon-cus-02.spheriq.net with ESMTP id k3EEpYl7027091 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 14 Apr 2006 14:51:35 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id DAAEBDA44; Fri, 14 Apr 2006 14:51:31 +0000 (GMT) Received: from mail1.cro.st.com (mail1.cro.st.com [164.129.40.131]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 897E04828E; Fri, 14 Apr 2006 14:51:31 +0000 (GMT) Received: from crx549.cro.st.com (crx549.cro.st.com [164.129.44.49]) by mail1.cro.st.com (MOS 3.5.8-GR) with ESMTP id CHE78185 (AUTH "frederic riss"); Fri, 14 Apr 2006 16:51:30 +0200 (CEST) Subject: Re: [RFC] Don't lose compilation directory in Dwarf2 line-tables From: Frederic RISS To: Daniel Jacobowitz Cc: Jim Blandy , GDB Patches In-Reply-To: <20060414140449.GA14270@nevyn.them.org> 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> <20060414140449.GA14270@nevyn.them.org> Content-Type: text/plain Date: Fri, 14 Apr 2006 14:51:00 -0000 Message-Id: <1145026289.14807.816.camel@crx549.cro.st.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit 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/msg00193.txt.bz2 On Fri, 2006-04-14 at 10:04 -0400, Daniel Jacobowitz wrote: > 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. Very true... I thought that doing it this way would solve a more general problem, but in fact when your project has several compilation directories it totally fails! > 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? :-) Seems I missed this thread. The idea is excellent. > 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. I don't have clear-cut opinion anymore either. If Jim expresses no other opinion until then, I'll send a patch implementing his suggestion beginning of next week.