From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18659 invoked by alias); 8 Jan 2008 19:54:48 -0000 Received: (qmail 18651 invoked by uid 22791); 8 Jan 2008 19:54:47 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 08 Jan 2008 19:54:20 +0000 Received: from zps77.corp.google.com (zps77.corp.google.com [172.25.146.77]) by smtp-out.google.com with ESMTP id m08JsFaD019734 for ; Tue, 8 Jan 2008 11:54:15 -0800 Received: from wa-out-1112.google.com (wafm38.prod.google.com [10.114.189.38]) by zps77.corp.google.com with ESMTP id m08JrOkE012211 for ; Tue, 8 Jan 2008 11:54:15 -0800 Received: by wa-out-1112.google.com with SMTP id m38so14214885waf.16 for ; Tue, 08 Jan 2008 11:54:14 -0800 (PST) Received: by 10.114.88.1 with SMTP id l1mr6471529wab.79.1199822054281; Tue, 08 Jan 2008 11:54:14 -0800 (PST) Received: by 10.115.107.7 with HTTP; Tue, 8 Jan 2008 11:54:14 -0800 (PST) Message-ID: Date: Tue, 08 Jan 2008 19:54:00 -0000 From: "Doug Evans" To: "Joel Brobecker" Subject: Re: gdb_realpath: dealing with ./ and ../ Cc: "Aleksandar Ristovski" , gdb@sourceware.org, "Ryan Mansfield" In-Reply-To: <20080108054518.GB20580@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2F6320727174C448A52CEB63D85D11F40A3F@nova.ott.qnx.com> <20080103170846.GA17263@caradoc.them.org> <20080107143212.GA5923@adacore.com> <20080108054518.GB20580@adacore.com> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-01/txt/msg00055.txt.bz2 On Jan 7, 2008 9:45 PM, Joel Brobecker wrote: > I have thought this over some more, and it looks like > indeed manual rewriting of the paths will be needed if we want to > be able to handle all the situations currently discussed. I think this point is still open for discussion, i.e. do we want to try to handle "all" the situations currently discussed. One can solve the 99.9% case without resorting to path rewriting, one just needs to know that one particular path is the path of the main source file. If one can know this (e.g. by an extra argument to start_subfile, or because the debug info readers have enough context to know it), then one can first do a full path comparison and if that fails and the file is the main file then do a basename comparison. In order to make progress I think we need to decide on whether we are going to try heuristics (like path normalization) to handle the 0.1% case. The 0.1% case being multiple files with the same base name as the main file. [For completeness sake, there may be more cases so the math might not add up.] And if so we also need to decide whether heuristics (like path normalization) will be applied to all files, or just the main file. The proposed patch applies normalization to all files, the dwarf patch applies it to just files that are potentially the main file and then only if there are multiple files with the same basename as the main file. Of course, we also need to decide on whether we're going to handle this problem at all. :-) Producers of debug info should follow rules more strictly, but I think consumers of debug info should be a bit lax if it's easy to do and reasonably useful. [One can still flag violations with complaints so producers get fixed - that's one thing that should be added to any patch that goes in. The dwarf spec is silent on this issue but I gather the intent is that paths must be consistent - this may get fixed in dwarf v4.] > Maybe I shouldn't have talked about complexity as this may be just me > needing time to understand the purpose of your patch. So I withdraw > that comment. Also remember that that patch also adds some simplification: All three call sites of dwarf2_start_subfile currently process fe->dir_index. One could move that into dwarf2_start_subfile of course, but there is still the issue of knowing a file is the main file. > My suggestion has two ideas behind it: > > I reallly think that the wrapper around start_subfile that adjusts > NAME and DIRNAME so that NAME is always a basename is a good step > forward, because it reduces the number of combinations we need to > handle during the matching phase later on. We don't have to handle > the case where NAME is a full path, or a relative path of a basename. Or one could instead store basename and fullname in struct subfile (where "fullname" is the complete path that's available). This way the comparison loop in start_subfile doesn't have to keep prepending directories, and can go back to the simple loop it use to be. [I still have an open question regarding why DIRNAME isn't prepended to NAME before going into the comparison loop: http://sourceware.org/ml/gdb-patches/2008-01/msg00091.html] > I think that the reorganization will not be necessary. I'd like to > make the subfile layer work in a way that the debug info reader would > only have to pass the name and dirname as-is, and be confident that > it'll just work. If one wants to handle this, and one wants to handle it in start_subfile, then I think start_subfile needs to know when it is passed the main file so that it can punt to heuristics only in this case. start_symtab is presumably a good place to tell start_subfile "this is the main file". Either that or maybe use last_source_file.