From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15307 invoked by alias); 17 Sep 2010 12:29:45 -0000 Received: (qmail 15297 invoked by uid 22791); 17 Sep 2010 12:29:44 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,MSGID_MULTIPLE_AT X-Spam-Check-By: sourceware.org Received: from mailhost.u-strasbg.fr (HELO mailhost.u-strasbg.fr) (130.79.200.152) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 17 Sep 2010 12:29:35 +0000 Received: from md1.u-strasbg.fr (md1.u-strasbg.fr [IPv6:2001:660:2402::186]) by mailhost.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id o8HCTIvq040607 ; Fri, 17 Sep 2010 14:29:18 +0200 (CEST) (envelope-from pierre.muller@ics-cnrs.unistra.fr) Received: from mailserver.u-strasbg.fr (ms1.u-strasbg.fr [IPv6:2001:660:2402:d::10]) by md1.u-strasbg.fr (8.14.4/jtpda-5.5pre1) with ESMTP id o8HCTHdx030401 ; Fri, 17 Sep 2010 14:29:18 +0200 (CEST) (envelope-from pierre.muller@ics-cnrs.unistra.fr) Received: from d620muller (gw-ics.u-strasbg.fr [130.79.210.225]) (user=mullerp mech=LOGIN) by mailserver.u-strasbg.fr (8.14.4/jtpda-5.5pre1) with ESMTP id o8HCTHp1024135 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Fri, 17 Sep 2010 14:29:17 +0200 (CEST) (envelope-from pierre.muller@ics-cnrs.unistra.fr) From: "Pierre Muller" To: "'Tom Tromey'" Cc: References: <20100731162500.32FAE5664F4@henry1.codesourcery.com> <20100817184407.GC3599@adacore.com> <20100818101406.GA2903@adacore.com> <15264.6257346079$1282142643@news.gmane.org> <004b01cb3faf$b07ed580$117c8080$@muller@ics-cnrs.unistra.fr> <001b01cb48ee$6b8425f0$428c71d0$@muller@ics-cnrs.unistra.fr> <44796.6229789474$1283326243@news.gmane.org> <000301cb4aa0$7c44fd70$74cef850$@muller@ics-cnrs.unistra.fr> <001f01cb5574$78252a60$686f7f20$@muller@ics-cnrs.unistra.fr> <20078.2261243605$1284672670@news.gmane.org> In-Reply-To: Subject: RE: Your INTERMEDIATE_ENCODING patch for Solaris Date: Fri, 17 Sep 2010 13:48:00 -0000 Message-ID: <001101cb5663$f6011c10$e2035430$@muller@ics-cnrs.unistra.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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: 2010-09/txt/msg00319.txt.bz2 =20 > -----Message d'origine----- > De=A0: gdb-patches-owner@sourceware.org [mailto:gdb-patches- > owner@sourceware.org] De la part de Tom Tromey > Envoy=E9=A0: Friday, September 17, 2010 4:13 AM > =C0=A0: Pierre Muller > Cc=A0: gdb-patches@sourceware.org > Objet=A0: Re: Your INTERMEDIATE_ENCODING patch for Solaris >=20 > >>>>> "Pierre" =3D=3D Pierre Muller > writes: >=20 > Pierre> Would it be possible to test an old libiconv on some other > platform? >=20 > I can't do this any time soon, but according to the libiconv NEWS file, > this feature was added in 1.5. So, perhaps we can relax the version > check to 0x105. I found the libiconv version 1.5 installed it on a x86 Open Solaris machine, modified gdb_wchar.h to use _LIBICONV_VERSION >=3D 0x105 and got an gdb executable linked to libiconv version 1.5, using --with-libiconv-prefix=3D/usr/local/src/test32 (the installation prefix I used for 1.5 libiconv). I tested charset.exp result on that executable, and got a lot of failures: =3D=3D=3D gdb Summary =3D=3D=3D # of expected passes 68 # of unexpected failures 51 /usr/local/src/gdb/build32/gdb/testsuite/../../gdb/gdb version 7.2.50.2010= 0916- cvs -nw -nx while using 1.13.1 libiconv version, I got this: =3D=3D=3D gdb Summary =3D=3D=3D # of expected passes 159 # of unexpected failures 2 But I was wondering if the problem is not coming from the fact that for 1.5 libiconv find_charset_names function directly calls 'iconv -l' (because iconvlist is not present in this version of the library). The iconv that is called is the /usr/bin/iconv not the one that comes with the installed library: /usr/local/src/test32/bin/iconv. On the other hand, as iconvlist function is not implemented in 1.5 version 'iconv -l' also doesn't work. This makes me believe that we should not attempt to call 'iconv -l' if we link in GNU libiconv and no iconvlist function exists. The list that is read in by 'iconv -l' call is the list of libc iconv supported charsets in a format that is mishandled by the code anyhow: (top-gdb) set charset gives this: Requires an argument. Valid arguments are auto, fromcode-tocode., Some, of,= those,=20 code, set, names, have, aliases, which, are, case-insensitive, and, describ= ed, in,=20 parentheses, following, the, canonical, name:, 5601, 646, (ASCII, US-ASCII , US_ASCII, USASCII), 646da, 646de, 646en, 646es, 646fr, 646it, 646sv, 8859= , 885 9-1, (ISO8859-1, ISO-8859-1, ISO8859_1, ISO_8859_1), 8859-10, (ISO8859-10, = ISO88 (.... the list is much longer,) The output of the libc iconv is not parsed correctly because aliases are within parenthesis that are not removed and an introduction sentence is not recognized. (top-gdb) set charset ASCII Undefined item: "ASCII". (top-gdb) set charset (ASCII Cannot convert between character sets `UTF-32' and `(ASCII' (top-gdb) set charset US_ASCII Cannot convert between character sets `UTF-32' and `US_ASCII' (top-gdb) set charset US-ASCII (top-gdb) p version $1 =3D "7.2.50.20100916-cvs" So you can see: 'ASCII' is refused by GDB because not in the 'wrong' list it created by 'iconv -l' call. '(ASCII' is accepted by GDB, but refused by iconv_open 'US_ASCII' is accepted by GDB, but refused by iconv_open, probably because 1.5 GNU libiconv does not recognize that alias, whereas 'US-ASCII' is accepted by GDB, and by iconv_open! That would mean that we should either: 1) only accept libiconv if it also has iconvlist (1.8 already has iconvlis= t, but there are some changes recorded in the ChangeLog after that). or 2) not call 'iconv -l' if libiconv has no iconvlist function and use only the standard list defined. I also downloaded version 1.8 of libiconv, and checked GDB linked to that version: the results of charset.exp are the same as 1.13.1 (2 FAILs) Pierre PS: Support of libc iconv for Solaris could probably be=20 enhanced by a better parsing of 'iconv -l' output...