This is the mail archive of the
mailing list for the GDB project.
Re: [RFA/commit] Improve gdb_realpath for Windows hosts
- From: asmwarrior <asmwarrior at gmail dot com>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 27 Dec 2011 20:25:48 +0800
- Subject: Re: [RFA/commit] Improve gdb_realpath for Windows hosts
- References: <firstname.lastname@example.org>
On 2011-12-23 1:14, Joel Brobecker wrote:
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.
* 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.
Someone said that "MAX_PATH" is not enough about several months ago when we were discussing some breakpoint issue