From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6510 invoked by alias); 6 Jan 2008 18:44:11 -0000 Received: (qmail 6500 invoked by uid 22791); 6 Jan 2008 18:44:10 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 06 Jan 2008 18:43:53 +0000 Received: from zps78.corp.google.com (zps78.corp.google.com [172.25.146.78]) by smtp-out.google.com with ESMTP id m06IhiCs019735 for ; Sun, 6 Jan 2008 18:43:45 GMT Received: from wa-out-1112.google.com (wafl24.prod.google.com [10.114.188.24]) by zps78.corp.google.com with ESMTP id m06IhbBw001694 for ; Sun, 6 Jan 2008 10:43:44 -0800 Received: by wa-out-1112.google.com with SMTP id l24so13960244waf.17 for ; Sun, 06 Jan 2008 10:43:44 -0800 (PST) Received: by 10.114.174.2 with SMTP id w2mr20286794wae.17.1199645024087; Sun, 06 Jan 2008 10:43:44 -0800 (PST) Received: by 10.115.107.7 with HTTP; Sun, 6 Jan 2008 10:43:44 -0800 (PST) Message-ID: Date: Sun, 06 Jan 2008 18:44:00 -0000 From: "Doug Evans" To: "Aleksandar Ristovski" Subject: Re: [RFA] patch for DW_AT_comp_dir/DW_AT_name vs .debug_line inco nsistencies Cc: gdb-patches@sourceware.org In-Reply-To: <2F6320727174C448A52CEB63D85D11F40A5A@nova.ott.qnx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2F6320727174C448A52CEB63D85D11F40A5A@nova.ott.qnx.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-01/txt/msg00098.txt.bz2 On Jan 5, 2008 10:43 PM, Aleksandar Ristovski wrote: > > > I took an easy out in scanning for a match, I just pick the first. I > > > can add the requisite code if folks think this is the way to go. > > I would think that yes, we need to do more to try "perfect" v.s. "less than > perfect" matches. Yep. That's an "implementation detail left for later" :-). I wanted to make sure the rest of the patch was "typing in the right direction" first. > I still believe we should do the following (I am assuming cu_file_name is an > absolute path). In the patch cu_file_name might not be an absolute path, but combined with comp_dir generally it is. > 1) Compare cu_file_name and fname; make sure fname is absolute, concat if > needed. They match? Great - pick that one. > > 2) Try less than perfect match: compare base names; Loop, however, through > all and see if exactly one match exists. If yes, great - pick that one. > > 3) If neither 1 or 2 worked, try with compacting absolute paths and > comparing compacted paths. If it matches, pick that one. If not... don't > know. > > Note: I don't think possibility of symlinks will spoil step 3. We simply try > to match compiler's idea about what it saw. I.e., at this point we are > playing with paths only (we can think of them as logical paths since > physical paths at this point may not exist at all on the host system where > gdb is running. In fact, we do not really care what the physical path is we > just want to reconstruct what compiler thought it compiled). (3) is where the fun begins, and symlinks can spoil things, but at this point we're into heuristic-land so things are already spoiled.