From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13682 invoked by alias); 22 Dec 2011 17:15:16 -0000 Received: (qmail 13647 invoked by uid 22791); 22 Dec 2011 17:15:11 -0000 X-SWARE-Spam-Status: No, hits=-3.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 22 Dec 2011 17:14:57 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 88DAF2BADE7; Thu, 22 Dec 2011 12:14:56 -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 ywX47UnpPzf0; Thu, 22 Dec 2011 12:14:56 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 11BA92BAD9D; Thu, 22 Dec 2011 12:14:56 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 29E0F145615; Thu, 22 Dec 2011 09:14:48 -0800 (PST) From: Joel Brobecker To: gdb-patches@sourceware.org Cc: Joel Brobecker Subject: [RFA/commit] Improve gdb_realpath for Windows hosts Date: Thu, 22 Dec 2011 17:31:00 -0000 Message-Id: <1324574084-7971-1-git-send-email-brobecker@adacore.com> 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: 2011-12/txt/msg00786.txt.bz2 Hello, I noticed that inserting a breakpoint on Windows hosts often does not work when the linespec involves a filename with its full path. For instance: (gdb) b c:/some/double/slashes/dir/foo.c:4 No source file named c:/some/double/slashes/dir/foo.c:4. (gdb) b c:\some\double\slashes\dir\foo.c:4 No source file named c:\some\double\slashes\dir\foo.c:4. The problem in this case comes from the fact that the compiler produced some debugging info where the filename had double backslaces (weird), as in `c:\\some\\double\\slashes\\dir'. On Unix platforms, this wouldn't be a problem, because gdb_realpath takes care of normalizing the path. But on windows, the implementation is just an xstrdup. This fixes the problem by enhancing gdb_realpath on Windows hosts. The code is inspired from libiberty's lrealpath. I decided to continue duplicating part of lrealpath rather than replacing everything by a call to lrealpath because I think that we actually want something slightly different: after normalizing the path, lrealpath then lowercases it. This is not idea of GDB, because it prevents us from displaying filenames using the correct casing. gdb/ChangeLog: * utils.c (gdb_realpath): Add better support for Windows hosts. Tested on x86-windows. Any objection to this? There is a performance cost, but this is just on par with what we do on Unix hosts, so I assume it's OK. Thanks, -- Joel --- gdb/utils.c | 19 +++++++++++++++++++ 1 files changed, 19 insertions(+), 0 deletions(-) diff --git a/gdb/utils.c b/gdb/utils.c index 16405d1..d55e6f1 100644 --- a/gdb/utils.c +++ b/gdb/utils.c @@ -3341,6 +3341,25 @@ gdb_realpath (const char *filename) } #endif + /* The MS Windows method. If we don't have realpath, we assume we + don't have symlinks and just canonicalize to a Windows absolute + path. GetFullPath converts ../ and ./ in relative paths to + absolute paths, filling in current drive if one is not given + or using the current directory of a specified drive (eg, "E:foo"). + It also converts all forward slashes to back slashes. */ + /* The file system is case-insensitive but case-preserving. + So we do not lowercase the path. Otherwise, we might not + be able to display the original casing in a given path. */ +#if defined (_WIN32) + { + char buf[MAX_PATH]; + DWORD len = GetFullPathName (filename, MAX_PATH, buf, NULL); + + if (len > 0 && len < MAX_PATH) + return xstrdup (buf); + } +#endif + /* This system is a lost cause, just dup the buffer. */ return xstrdup (filename); } -- 1.7.1