This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] Fix cygwin compilation failure due to nameless LOAD_DLL_DEBUG_EVENT causes ntdll.dll to be missing
- From: Eli Zaretskii <eliz at gnu dot org>
- To: gdb-patches at sourceware dot org
- Date: Wed, 18 Dec 2013 17:45:15 +0200
- Subject: Re: [RFA] Fix cygwin compilation failure due to nameless LOAD_DLL_DEBUG_EVENT causes ntdll.dll to be missing
- Authentication-results: sourceware.org; auth=none
- References: <52ab8d0e dot 8aa2420a dot 30ff dot ffffd8f1SMTPIN_ADDED_BROKEN at mx dot google dot com> <52AF3493 dot 9090708 at redhat dot com> <20131218112045 dot GQ30010 at calimero dot vinschen dot de>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> Date: Wed, 18 Dec 2013 12:20:45 +0100
> From: Corinna Vinschen <vinschen@redhat.com>
>
> In theory, you should never use the ANSI API on Windows, unless you're
> still building GDB for Windows 9x, which should be really, really dead
> by now, hopefully.
Did we decide to drop Windows 9X support? Unicode APIs will not work
on Windows 9X (in fact, I think Windows will refuse to run such a
gdb.exe), unless we link against unicows.dll.
> - The ANSI API only supports a single- or doublebyte codeset in almost
> all language versions of Windows. There are only a handful languages
> which are using UTF-8 as ANSI codeset on Windows, most use something
> like CP1252 or some other codeset which is not capable of handling all
> UNICODE characters.
>
> - The ANSI API restricts filenames to MAX_PATH (260) characters, while
> the UNICODE API and the underlying OS allow paths of up to 32K.
But the MinGW build of GDB is still in the ANSI codepage world, and
will probably remain there for the observable future, because Windows
runtime and file APIs don't understand UTF-8 encoding, and switching
to wchar_t everywhere in GDB is unthinkable. So unless someone
volunteers to provide wrappers for all the library functions GDB calls
that accept or return file names, and make those wrappers accept UTF-8
encoded file names, we are stuck.
> Cygwin is using the UNICODE and native NT APIs exclusively
Sure, but Cygwin uses its own runtime.
> so paths in Cygwin are only restricted by the maximum OS capability
> of 32K, and the influence of the PATH_MAX setting of 4096.
Are you sure that 32K capability cannot be had with ANSI file names
using the \\?\ notation?