From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3875 invoked by alias); 19 Dec 2013 18:33:46 -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 3866 invoked by uid 89); 19 Dec 2013 18:33:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mtaout20.012.net.il Received: from mtaout20.012.net.il (HELO mtaout20.012.net.il) (80.179.55.166) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 19 Dec 2013 18:33:44 +0000 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MY200D00GQV9400@a-mtaout20.012.net.il> for gdb-patches@sourceware.org; Thu, 19 Dec 2013 20:33:41 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MY200BC4GW5EGA1@a-mtaout20.012.net.il> for gdb-patches@sourceware.org; Thu, 19 Dec 2013 20:33:41 +0200 (IST) Date: Thu, 19 Dec 2013 18:33:00 -0000 From: Eli Zaretskii Subject: Re: [RFA] Fix cygwin compilation failure due to nameless LOAD_DLL_DEBUG_EVENT causes ntdll.dll to be missing In-reply-to: <20131218205416.GI30010@calimero.vinschen.de> To: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83fvpobsh3.fsf@gnu.org> References: <20131218112045.GQ30010@calimero.vinschen.de> <83bo0ecgdw.fsf@gnu.org> <20131218160707.GV30010@calimero.vinschen.de> <834n66ccs9.fsf@gnu.org> <20131218171819.GY30010@calimero.vinschen.de> <831u1acblu.fsf@gnu.org> <20131218173155.GA30010@calimero.vinschen.de> <83zjnyaupt.fsf@gnu.org> <20131218191757.GC30010@calimero.vinschen.de> <83y53iapy6.fsf@gnu.org> <20131218205416.GI30010@calimero.vinschen.de> X-IsSubscribed: yes X-SW-Source: 2013-12/txt/msg00795.txt.bz2 > Date: Wed, 18 Dec 2013 21:54:16 +0100 > From: Corinna Vinschen > > > > There's a lot of theory here. Did you actually *try* it? > > > > No. Who can afford to try everything, unless they are paying you to > > do that? > > Well, it might not take much more time than musings in email... > > > > I just did: > > > > > > =========================================== > > > #include > > > #include > > > > > > int main(void) > > > { > > > FILE *fp; > > > > > > fp = _wfopen (L"\\\\?\\C:\\Windows\\System32\\ntdll.dll", L"r"); > > > if (!fp) > > > printf ("_wfopen w/ long pathname fails, errno = %d\n", errno); > > > else > > > { > > > printf ("_wfopen w/ long pathname works\n"); > > > fclose(fp); > > > } > > > return 0; > > > } > > > =========================================== > > > > Thanks, that's good to know. But that's just one CRT function. There > > are a gazillion of them, and I'm quite sure some use MAX_PATH of 260 > > internally. Just grep the sources of the CRT functions. > > Sigh. Since you were that unhappy, I took some time to test about a dozen of the more popular CRT functions that deal with file names and accept wchar_t arguments. Most of them worked with long file names in the \\?\ format, but some didn't. First, _wchdir failed consistently with file names longer than 260. Which might not be a surprise, since SetCurrentDirectoryW is documented to be limited to MAX_PATH characters. But it does mean that any application which wishes to lift the 260-char limitation will need to replace chdir and getcwd (and DTRT for each thread). Next, _wstat fails for any file name in the \\?\ form, even if it doesn't exceed the 260-character limit. By contrast, FindFirstFileW, on which AFAIK the MS implementation of 'stat' is based, has no problem with such file names, and works with filenames up to 32K characters. On Windows XP (but not on Windows 7), _wfullpath also failed for long file names. The upshot of all this is that it's not enough to just switch to wchar_t and \\?\ form of file names, there's some non-trivial support code that will need to be written to take advantage of that in any sufficiently large application (such as GDB). Moreover, even just using Unicode APIs is of questionable value in GDB (as in any other console program on Windows), because: . supporting Unicode on the console will need very serious changes in Readline and in ui-*.c modules; without such changes, one can never enter or display file names outside of the current ANSI codepage . the Windows console has very weak support for non-ASCII fonts even when Unicode APIs are used to read and write to the console (basically, anything outside of Europe cannot be displayed) . any external libraries against which GDB is linked are likely not to support Unicode file names or UTF-16 text, so you cannot easily communicate with them without losing Unicode capabilities . suppose you get from a Unicode API, such as GetModuleFileNameW, a file name that cannot be expressed in the current ANSI codepage -- what can you do with such a file name in GDB? probably nothing except displaying an error message So I think the benefits of switching the MinGW GDB to Unicode APIs are questionable, although if someone steps forward and does a clean job for that, I'm quite sure the patches will be more than welcome.