From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10850 invoked by alias); 18 Dec 2013 16:07:12 -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 10840 invoked by uid 89); 18 Dec 2013 16:07:12 -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: calimero.vinschen.de Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 18 Dec 2013 16:07:10 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id 725581A082F; Wed, 18 Dec 2013 17:07:07 +0100 (CET) Date: Wed, 18 Dec 2013 16:07:00 -0000 From: Corinna Vinschen To: gdb-patches@sourceware.org Subject: Re: [RFA] Fix cygwin compilation failure due to nameless LOAD_DLL_DEBUG_EVENT causes ntdll.dll to be missing Message-ID: <20131218160707.GV30010@calimero.vinschen.de> Reply-To: gdb-patches@sourceware.org Mail-Followup-To: gdb-patches@sourceware.org References: <52ab8d0e.8aa2420a.30ff.ffffd8f1SMTPIN_ADDED_BROKEN@mx.google.com> <52AF3493.9090708@redhat.com> <20131218112045.GQ30010@calimero.vinschen.de> <83bo0ecgdw.fsf@gnu.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8MZM6zh5Bb05FW+3" Content-Disposition: inline In-Reply-To: <83bo0ecgdw.fsf@gnu.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2013-12/txt/msg00706.txt.bz2 --8MZM6zh5Bb05FW+3 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2636 On Dec 18 17:45, Eli Zaretskii wrote: > > Date: Wed, 18 Dec 2013 12:20:45 +0100 > > From: Corinna Vinschen > >=20 > > 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. >=20 > 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. I didn't say that. I said I *hoped* that 9x is dead by now. > > - 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. > >=20 > > - The ANSI API restricts filenames to MAX_PATH (260) characters, while > > the UNICODE API and the underlying OS allow paths of up to 32K. >=20 > 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, They do understand UNICODE if you use the wide char functions. > 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. For a start it might be feasible to use the already existing UNICODE code in windows-nat.c. Implementing wrappers for the msvcrt functions used elsewhere in the code at one point shouldn't be that hard, just a bit of boring work. > > Cygwin is using the UNICODE and native NT APIs exclusively >=20 > Sure, but Cygwin uses its own runtime. >=20 > > so paths in Cygwin are only restricted by the maximum OS capability > > of 32K, and the influence of the PATH_MAX setting of 4096. >=20 > Are you sure that 32K capability cannot be had with ANSI file names > using the \\?\ notation? Yes. The \\?\ notation only works in the UNICODE API[*]. The reason is that the ANSI API is just a thin layer over the actual UNICODE functionality, and the conversion from ANSI to UNICODE is done using a per-thread fixed-size buffer of 520 bytes. The ANSI API is really something which should be avoided these days. Corinna [*] http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=3D= vs.85%29.aspx --=20 Corinna Vinschen Cygwin Maintainer Red Hat --8MZM6zh5Bb05FW+3 Content-Type: application/pgp-signature Content-length: 836 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAEBAgAGBQJSscgrAAoJEPU2Bp2uRE+gKqgP/j6xVWel8YAv10VH6ZK+wlqc xY95ozecZ3rWfl55XmC4cgCqWYSyoZXPwQ3ao59syJXRBBgZnbDgPgKewr9Q9fRG 0W/UntytyzWygkNkXS5WiZuzBErWfEPbAWdIr/59oWnp0zoVcpktVwFFfI3gYvkb xEeYO0CwLTQwOjZcPz+SLyoA4yyx45StH7rYX5bisqURUiLOEfaNAMdDcRU9PB2Q V5BZJlmZQ4WsCirq2kOXSPANxk2m2Nc4mU3Bvc9wWsnGGaWm4S936Xvptxb3s3PO yXkYB/CaMFa/XiQ6vXL3XP+g4uy5n7+PEnNiyyYzX24G/qq2LqHfXqAz1LJCFqcl nZibm9TbE1mVvClYybBjzOCFK07IL6BDm4kPHo89S8IihLxLaUXUWQkZqpagioBZ bEbFzu5qg1GvcmpOfDfs72xgR+hj8f2FB4wwcATCqK1Be20LDDElG7WlkxC0FmRL evX0uDbXN7XJ7jMGANfYn/sLs2+4k++D3HUij0zG9Uw5O+Hs4ZTYvVvf0KLq/xJ9 zuMMrogst5U3mt9SyTm4LYoLiD3N95CvfYXVdTyPsP/9dD74D1gBQ1WJkOLrROin dhToQQyumMy5Z9rfuCOIPFQ30/cTWF6jEoDjJ2QFJU0R9ROhB8VWA/hK5nxCyDOy aa6bcpFu6aetHuyUqydY =jxX4 -----END PGP SIGNATURE----- --8MZM6zh5Bb05FW+3--