From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13838 invoked by alias); 14 Apr 2006 07:32:43 -0000 Received: (qmail 13829 invoked by uid 22791); 14 Apr 2006 07:32:42 -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 07:32:39 +0000 Received: from lon-out-03.spheriq.net ([195.46.50.131]) by lon-del-01.spheriq.net with ESMTP id k3E7WTRk023050 for ; Fri, 14 Apr 2006 07:32:32 GMT Received: from lon-cus-02.spheriq.net (lon-cus-02.spheriq.net [195.46.50.38]) by lon-out-03.spheriq.net with ESMTP id k3E7WSGo029575 for ; Fri, 14 Apr 2006 07:32:28 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 k3E7WQ6S007310 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 14 Apr 2006 07:32:27 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 A5AA1DA48; Fri, 14 Apr 2006 07:32:25 +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 59BFD47EC0; Fri, 14 Apr 2006 07:32:25 +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 CHE67291 (AUTH "frederic riss"); Fri, 14 Apr 2006 09:32:23 +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: <8f2776cb0604131049i69e9b20fv78e60c023f245e56@mail.gmail.com> References: <1144927446.14807.561.camel@crx549.cro.st.com> <8f2776cb0604131049i69e9b20fv78e60c023f245e56@mail.gmail.com> Content-Type: text/plain Date: Fri, 14 Apr 2006 07:32:00 -0000 Message-Id: <1144999942.14807.721.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/msg00179.txt.bz2 Him Jim, Thanks for your comments. On Thu, 2006-04-13 at 10:49 -0700, Jim Blandy wrote: > Hi, Frederic. Thanks for the patch! I think you're right about how > GDB should interpret DW_AT_comp_dir and directories in the line number > information. Some comments: Great. > You should generally include a ChangeLog entry along with the patch; > you'll have to write it anyway, and it helps reviewers get oriented > for what they're going to see in the patch itself. Will do for the next round. > Ideally, the use of SLASH_STRING would be a separate patch, but that's > not a big deal. Not a big deal for me to do a separate patch. > When you add a new argument to dwarf2_start_subfile, you need to > adjust the comments above the file that describe what the arguments > mean. Yep > The patch changes the logic of dwarf2_start_subfile in a circuitous > way. If dirname and comp_dir are absolute and different, and filename > is relative, then you end up passing start_subfile two absolute paths. > I'd rather see the code changed like this: I agree that the way it was done made dwarf2_start_subfile quite strange to read. > - Since dwarf2_start_subfile now knows about comp_dir, there's no need > to use comp_dir as a default in dwarf_decode_lines. Just pass NULL > for dirname when the dir_index is zero. That's a good idea, it makes things simpler. I've a cleaned up patch for that, but I'm not sure sure about your next proposal: > - 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. > Also, in the comments, "loose" is the opposite of "tight"; you mean "lose". Doh... back to school :-) Regards, Fred