From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6813 invoked by alias); 13 Apr 2006 17:49:17 -0000 Received: (qmail 6803 invoked by uid 22791); 13 Apr 2006 17:49:17 -0000 X-Spam-Check-By: sourceware.org Received: from xproxy.gmail.com (HELO xproxy.gmail.com) (66.249.82.195) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 13 Apr 2006 17:49:15 +0000 Received: by xproxy.gmail.com with SMTP id s16so1292872wxc for ; Thu, 13 Apr 2006 10:49:13 -0700 (PDT) Received: by 10.70.28.5 with SMTP id b5mr977809wxb; Thu, 13 Apr 2006 10:49:13 -0700 (PDT) Received: by 10.70.125.5 with HTTP; Thu, 13 Apr 2006 10:49:13 -0700 (PDT) Message-ID: <8f2776cb0604131049i69e9b20fv78e60c023f245e56@mail.gmail.com> Date: Thu, 13 Apr 2006 17:49:00 -0000 From: "Jim Blandy" To: "Frederic RISS" Subject: Re: [RFC] Don't loose compilation directory in Dwarf2 line-tables Cc: "GDB Patches" In-Reply-To: <1144927446.14807.561.camel@crx549.cro.st.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <1144927446.14807.561.camel@crx549.cro.st.com> 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/msg00167.txt.bz2 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: 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. Ideally, the use of SLASH_STRING would be a separate patch, but that's not a big deal. 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. 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: - 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. - 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.) Also, in the comments, "loose" is the opposite of "tight"; you mean "lose".