From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15499 invoked by alias); 28 Nov 2014 03:43:20 -0000 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 Received: (qmail 15484 invoked by uid 89); 28 Nov 2014 03:43:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Fri, 28 Nov 2014 03:43:06 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id B4F5711670F; Thu, 27 Nov 2014 22:43:04 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id aJeRLtOQoga1; Thu, 27 Nov 2014 22:43:04 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 57E2E1166B3; Thu, 27 Nov 2014 22:43:04 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 8B96F40F79; Fri, 28 Nov 2014 07:43:00 +0400 (RET) Date: Fri, 28 Nov 2014 03:43:00 -0000 From: Joel Brobecker To: Yao Qi Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 6/7] Use canonicalize_file_name unconditionally Message-ID: <20141128034300.GH5042@adacore.com> References: <1416980800-21408-1-git-send-email-yao@codesourcery.com> <1416980800-21408-7-git-send-email-yao@codesourcery.com> <20141127073600.GA5042@adacore.com> <87r3woc9aw.fsf@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87r3woc9aw.fsf@codesourcery.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2014-11/txt/msg00696.txt.bz2 Hi Yao, > > I guess one step at a time, but why not use canonicalize_file_name > > on Windows hosts as well? My question is not necessarily to suggest > > that we should be doing it, but rather whether you know of a reason > > why we should not be doing it... > > The code handling Windows host was added by your patch below > > [RFA/commit] Improve gdb_realpath for Windows hosts > https://sourceware.org/ml/gdb-patches/2011-12/msg00785.html > > in order to handle a weird case that compiler produces some debug > info where the path has double backslashes. I am not sure gnulib > realpath is able to handle such case, so I leave the code for Windows > host there. Arf! :-) canonicalize_file_name does, as far as I can tell, collapse multiple backslashes, but there is one critical difference between both functions: GetFullPathName just performs the job mechanically without checking that the path is at all valid, while canonicalize_file_name requires the path to exist: /* Return the canonical absolute name of file NAME. A canonical name does not contain any ".", ".." components nor any repeated file name separators ('/') or symlinks. All components must exist. The result is malloc'd. */ Given how frequent it is for source files to be unavailable, I would say that it would be useful to preserve the GetFullPathName behavior for those files as well, and allow users to set breakpoints without having to worry about how many backslashes GCC has been using. Or said differently, I agree with your decision :-). I am taking a note to: 1. Add an extra comment to this part of the code once you've pushed your patch; 2. Double-check what newer versions of GCC do. At some point, perhaps we can declare a minimum GCC version that we fully support and then mark this code area for possible removal if it ever starts causing extra work. -- Joel