RE: Your INTERMEDIATE_ENCODING patch for Solaris

["Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>]

 

> -----Message d'origine-----
> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Tom Tromey
> Envoyé : Friday, September 17, 2010 4:13 AM
> À : Pierre Muller
> Cc : gdb-patches@sourceware.org
> Objet : Re: Your INTERMEDIATE_ENCODING patch for Solaris
> 
> >>>>> "Pierre" == Pierre Muller <pierre.muller@ics-cnrs.unistra.fr>
> writes:
> 
> Pierre>   Would it be possible to test an old libiconv on some other
> platform?
> 
> 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 >= 0x105
and got an gdb executable linked to libiconv version 1.5,
using --with-libiconv-prefix=/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:
                === gdb Summary ===

# of expected passes            68
# of unexpected failures        51
/usr/local/src/gdb/build32/gdb/testsuite/../../gdb/gdb version  7.2.50.20100916-
cvs -nw -nx

  while using 1.13.1 libiconv version, I got this:
                === gdb Summary ===

# 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, 
code, set, names, have, aliases, which, are, case-insensitive, and, described, in, 
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 = "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 iconvlist,
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 
enhanced by a better parsing of 'iconv -l' output...