From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15561 invoked by alias); 7 Jan 2008 17:00:56 -0000 Received: (qmail 15550 invoked by uid 22791); 7 Jan 2008 17:00:55 -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; Mon, 07 Jan 2008 17:00:28 +0000 Received: from zps36.corp.google.com (zps36.corp.google.com [172.25.146.36]) by smtp-out.google.com with ESMTP id m07H0Pcd012636 for ; Mon, 7 Jan 2008 09:00:26 -0800 Received: from wa-out-1112.google.com (wagn4.prod.google.com [10.114.215.4]) by zps36.corp.google.com with ESMTP id m07H026n006609 for ; Mon, 7 Jan 2008 09:00:25 -0800 Received: by wa-out-1112.google.com with SMTP id n4so32826327wag.6 for ; Mon, 07 Jan 2008 09:00:24 -0800 (PST) Received: by 10.114.12.9 with SMTP id 9mr22429934wal.23.1199725223695; Mon, 07 Jan 2008 09:00:23 -0800 (PST) Received: by 10.115.107.7 with HTTP; Mon, 7 Jan 2008 09:00:23 -0800 (PST) Message-ID: Date: Mon, 07 Jan 2008 17:00: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: <20080107143212.GA5923@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> 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/msg00038.txt.bz2 On Jan 7, 2008 6:32 AM, Joel Brobecker wrote: > The reason why I agree that the changes should be done inside > start-subfiles is that we don't want to have to handle this sort of > problem with every debug info reader. This was, the handling is > centralized. It also looks a lot simpler than the patches I have seen > that touch the DWARF reader. To what extent is the dwarf patch more complex because it handles the possibility of multiple matches with the basename of the main source file. Assume there's only one file with the basename of the main file name and things become a lot simpler. See http://sourceware.org/ml/gdb-patches/2008-01/msg00090.html. One could rewrite that patch to keep dwarf2_start_subfile, but one would have to pass an additional parameter so it would know if it's dealing with the main source file. The patch as submitted just reorganizes things so that other solutions(/heuristics) are possible without major reworking of the code (the patch itself had to do some reworking, but once that's done it's done (in the problem space being discussed)). Plus it simplifies all call sites to dwarf2_start_subfile/start_subfile. Previously, each call site had to process fe->dir_index, and there are three of them. Handling the issue in each debug info reader is an important consideration and may or may not be a problem. One would need to examine to what extent the issue exists in the other readers, and to what extent start_subfile can solve it and still be debug-format independent without being more complex. > The one thing that this might break, however, is when the user > provides a relative path in the break command: > > (gdb) break bar/main.c > > As a matter of fact, this is already broken if DW_AT_name is main.c > and not bar/main.c. So I'm pretty sure that it'll break it more. > But the good news is that it would be easy to fix it: Modify the > matching to concat the dirname and basename and do the match with > that. > > Does this sound like it would work? It seems like directory names need to be included in the file name comparison by start_subfile to some extent, otherwise headers with the same basename will match each other. e.g. a/foo.h: int afoo () { return 0; } b/foo.h: int bfoo () { return 0; } foo.c: #include "a/foo.h" #include "b/foo.h" int main () { return afoo () + bfoo (); }