From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4624 invoked by alias); 14 Apr 2006 08:23:09 -0000 Received: (qmail 4616 invoked by uid 22791); 14 Apr 2006 08:23:09 -0000 X-Spam-Check-By: sourceware.org Received: from fra-del-03.spheriq.net (HELO fra-del-03.spheriq.net) (195.46.51.99) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 14 Apr 2006 08:23:06 +0000 Received: from fra-out-01.spheriq.net (fra-out-01.spheriq.net [195.46.51.129]) by fra-del-03.spheriq.net with ESMTP id k3E8N3H5005279 for ; Fri, 14 Apr 2006 08:23:03 GMT Received: from fra-cus-01.spheriq.net (fra-cus-01.spheriq.net [195.46.51.37]) by fra-out-01.spheriq.net with ESMTP id k3E8N0r8016935 for ; Fri, 14 Apr 2006 08:23:02 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by fra-cus-01.spheriq.net with ESMTP id k3E8MwAQ006427 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 14 Apr 2006 08:22:59 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 90D3FDA42; Fri, 14 Apr 2006 08:22:58 +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 477E147F86; Fri, 14 Apr 2006 08:22:58 +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 CHE68745 (AUTH "frederic riss"); Fri, 14 Apr 2006 10:22:56 +0200 (CEST) Subject: Re: [RFC] Don't lose compilation directory in Dwarf2 line-tables From: Frederic RISS To: Jim Blandy Cc: GDB Patches In-Reply-To: <8f2776cb0604140041o63c56c2xa9113d3c4ee259d@mail.gmail.com> 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> Content-Type: text/plain Date: Fri, 14 Apr 2006 08:23:00 -0000 Message-Id: <1145002976.14807.744.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/msg00184.txt.bz2 On Fri, 2006-04-14 at 00:41 -0700, Jim Blandy wrote: > On 4/14/06, Frederic RISS wrote: > > > - Then, at the top of dwarf2_start_subfile, check if dirname is > > > relative, and if comp_dir is available, prepend comp_dir to it. At > > > this point, we know dirname is as absolute as it can be. Then proceed > > > as in the original unpatched code. (Watch out for allocation issues.) > > > > I don't think we should concat comp_dir and dirname. In my mind, > > comp_dir makes only sense as an 'independant' information. Or the other > > way around: dirname gives you information about your source tree > > structure, and you lose it by prepending comp_dir to it. Have you an > > objection to storing "dirname/filename" as filename and comp_dir as > > directory? Maybe this makes only sense when dirname is also relative > > like in the snippet that Jason posted. Once we agree on this part, I'll > > post an updated patch. > > We agree that, when dirname is absolute, comp_dir shouldn't get used at all. OK > 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. > I think the filename passed to start_subfile should be > free of leading directory components; I believe this is necessary to > make things like "print 'foo.c'::x" work. I don't think it is necessary, because I have examples of this working here. Moreover, if you're right on this, then we should add another patch that sanitizes DW_AT_name before creating symtabs. Like I said in my first mail, if the compiler accesses your source file with a relative path, then you'll get a relative path in the comp unit's DW_AT_name. But I'm quite sure that this would break some setups. I just looked up why it isn't an issue to have relative paths in the symtab's filename. In symtab.c::lookup_symtab, after a search on the full symtab name we do: /* Now, search for a matching tail (only if name doesn't have any dirs) */ if (lbasename (name) == name) ALL_SYMTABS (objfile, s) { if (FILENAME_CMP (lbasename (s->filename), name) == 0) return s; }