Configuring gdb_wchar.h

Configuring gdb_wchar.h

[Eli Zaretskii]

gdb_wchar.h and the corresponding configury test are too naive: they
assume that if wchar.h exists, the full array of wide-character
functions, such as wcslen, iswprint, iswdigit, and btowc, also exist.
It needs to test for the individual functions as well, or at least for
some of them.

The actual case in point is the DJGPP build.  The DJGPP library has
wchar.h and there's a port of libiconv, but the functions gdb_wchar.h
expects for wide character support are not there.

Re: Configuring gdb_wchar.h

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

Eli> The actual case in point is the DJGPP build.  The DJGPP library has
Eli> wchar.h and there's a port of libiconv, but the functions gdb_wchar.h
Eli> expects for wide character support are not there.

Thanks for the report.

Please try the appended patch.  I've included the auto* output in this
patch in case you don't have the right versions on your DJGPP machine.

I chose btowc as a sentinel function.  And, I separated out the "phony
iconv" and "wchar_t support" cases, so that systems that have the
former but not the latter will gracefully choose slightly degraded
functionality.

Tom

diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index b6f86a7..f2b19c3 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,14 @@
+2009-04-13  Tom Tromey  <tromey@redhat.com>
+
+	* c-lang.c (c_emit_char): Use INTERMEDIATE_ENCODING.
+	(c_printstr): Likewise.
+	* charset.c (make_wchar_iterator): Use INTERMEDIATE_ENCODING.
+	* gdb_wchar.h: Check HAVE_BTOWC.  Split PHONY_ICONV and wchar
+	cases.
+	(INTERMEDIATE_ENCODING): New define.
+	* configure, config.in: Rebuild.
+	* configure.ac: Check for btowc.
+
 2009-04-10  Jan Kratochvil  <jan.kratochvil@redhat.com>
 
 	* gdbtypes.c: Remove excessive parentheses at the return keywords.
diff --git a/gdb/c-lang.c b/gdb/c-lang.c
index 0c9e4f8..139d219 100644
--- a/gdb/c-lang.c
+++ b/gdb/c-lang.c
@@ -296,7 +296,7 @@ c_emit_char (int c, struct type *type, struct ui_file *stream, int quoter)
   obstack_init (&output);
   make_cleanup_obstack_free (&output);
 
-  convert_between_encodings ("wchar_t", host_charset (),
+  convert_between_encodings (INTERMEDIATE_ENCODING, host_charset (),
 			     obstack_base (&wchar_buf),
 			     obstack_object_size (&wchar_buf),
 			     1, &output, translit_char);
@@ -562,7 +562,7 @@ c_printstr (struct ui_file *stream, struct type *type, const gdb_byte *string,
   obstack_init (&output);
   make_cleanup_obstack_free (&output);
 
-  convert_between_encodings ("wchar_t", host_charset (),
+  convert_between_encodings (INTERMEDIATE_ENCODING, host_charset (),
 			     obstack_base (&wchar_buf),
 			     obstack_object_size (&wchar_buf),
 			     1, &output, translit_char);
diff --git a/gdb/charset.c b/gdb/charset.c
index 14862e7..c358940 100644
--- a/gdb/charset.c
+++ b/gdb/charset.c
@@ -527,7 +527,7 @@ make_wchar_iterator (const gdb_byte *input, size_t bytes, const char *charset,
   struct wchar_iterator *result;
   iconv_t desc;
 
-  desc = iconv_open ("wchar_t", charset);
+  desc = iconv_open (INTERMEDIATE_ENCODING, charset);
   if (desc == (iconv_t) -1)
     perror_with_name ("Converting character sets");
 
diff --git a/gdb/config.in b/gdb/config.in
index 0d5effa..ab0c840 100644
--- a/gdb/config.in
+++ b/gdb/config.in
@@ -70,6 +70,9 @@
 /* Define to 1 if you have the <bp-sym.h> header file. */
 #undef HAVE_BP_SYM_H
 
+/* Define to 1 if you have the `btowc' function. */
+#undef HAVE_BTOWC
+
 /* Define to 1 if you have the `canonicalize_file_name' function. */
 #undef HAVE_CANONICALIZE_FILE_NAME
 
diff --git a/gdb/configure b/gdb/configure
index 51f35f5..e06a451 100755
--- a/gdb/configure
+++ b/gdb/configure
@@ -15776,10 +15776,11 @@ fi
 
 
 
+
 for ac_func in canonicalize_file_name realpath getrusage getuid \
                 getgid poll pread64 sbrk setpgid setpgrp setsid \
 		sigaction sigprocmask sigsetmask socketpair syscall \
-		ttrace wborder setlocale iconvlist libiconvlist
+		ttrace wborder setlocale iconvlist libiconvlist btowc
 do
 as_ac_var=`echo "ac_cv_func_$ac_func" | $as_tr_sh`
 echo "$as_me:$LINENO: checking for $ac_func" >&5
diff --git a/gdb/configure.ac b/gdb/configure.ac
index 821dffe..88bd8a6 100644
--- a/gdb/configure.ac
+++ b/gdb/configure.ac
@@ -796,7 +796,7 @@ AC_FUNC_VFORK
 AC_CHECK_FUNCS([canonicalize_file_name realpath getrusage getuid \
                 getgid poll pread64 sbrk setpgid setpgrp setsid \
 		sigaction sigprocmask sigsetmask socketpair syscall \
-		ttrace wborder setlocale iconvlist libiconvlist])
+		ttrace wborder setlocale iconvlist libiconvlist btowc])
 AM_LANGINFO_CODESET
 
 # Check the return and argument types of ptrace.  No canned test for
diff --git a/gdb/gdb_wchar.h b/gdb/gdb_wchar.h
index 583140e..07a6c87 100644
--- a/gdb/gdb_wchar.h
+++ b/gdb/gdb_wchar.h
@@ -19,13 +19,36 @@
 #ifndef GDB_WCHAR_H
 #define GDB_WCHAR_H
 
-/* If this host has wchar_t and if iconv is available (perhaps via GNU
-   libiconv), then we arrange to use those.  Otherwise, we provide a
-   phony iconv which only handles a single character set, and we
-   provide wrappers for the wchar_t functionality we use.  */
-#if defined(HAVE_ICONV) && defined(HAVE_WCHAR_H)
-
+/* We handle three different modes here.
+   
+   Capable systems have the full suite: wchar_t support and iconv
+   (perhaps via GNU libiconv).  On these machines, full functionality
+   is available.
+   
+   DJGPP is known to have libiconv but not wchar_t support.  On
+   systems like this, we use the narrow character functions.  The full
+   functionality is available to the user, but many characters (those
+   outside the narrow range) will be displayed as escapes.
+   
+   Finally, some systems do not have iconv.  Here we provide a phony
+   iconv which only handles a single character set, and we provide
+   wrappers for the wchar_t functionality we use.  */
+
+
+#define INTERMEDIATE_ENCODING "wchar_t"
+
+#if defined (HAVE_ICONV)
 #include <iconv.h>
+#else
+/* This define is used elsewhere so we don't need to duplicate the
+   same checking logic in multiple places.  */
+#define PHONY_ICONV
+#endif
+
+/* We use "btowc" as a sentinel to detect functioning wchar_t
+   support.  */
+#if defined (HAVE_ICONV) && defined (HAVE_WCHAR_H) && defined (HAVE_BTOWC)
+
 #include <wchar.h>
 #include <wctype.h>
 
@@ -53,10 +76,15 @@ typedef int gdb_wint_t;
 
 #define LCST(X) X
 
-/* This define is used elsewhere so we don't need to duplicate the
-   same checking logic in multiple places.  */
-#define PHONY_ICONV
+/* If we are using the narrow character set, we want to use the host
+   narrow encoding as our intermediate encoding.  However, if we are
+   also providing a phony iconv, we might as well just stick with
+   "wchar_t".  */
+#ifndef PHONY_ICONV
+#undef INTERMEDIATE_ENCODING
+#define INTERMEDIATE_ENCODING host_charset ()
+#endif
 
-#endif /* defined(HAVE_ICONV) && defined(HAVE_WCHAR_H) */
+#endif
 
 #endif /* GDB_WCHAR_H */

Re: Configuring gdb_wchar.h

[Eli Zaretskii]

> Cc: gdb-patches@sources.redhat.com
> From: Tom Tromey <tromey@redhat.com>
> Date: Mon, 13 Apr 2009 11:54:12 -0600
> 
> >>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
> 
> Eli> The actual case in point is the DJGPP build.  The DJGPP library has
> Eli> wchar.h and there's a port of libiconv, but the functions gdb_wchar.h
> Eli> expects for wide character support are not there.
> 
> Thanks for the report.
> 
> Please try the appended patch.

It compiles and links okay, thanks.  Do you want me to test some
feature(s) to make sure the resulting binary works as expected?

> I've included the auto* output in this
> patch in case you don't have the right versions on your DJGPP machine.

Thanks, it does help.  I don't have the autotools installed here at
all, because I use them only very seldom.  If I need to run them, I
usually do so on one of the gnu.org machines where I have a login
account.  So having the patches for the configure script and config.in
does make the job easier.

Re: Configuring gdb_wchar.h

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

Tom> Please try the appended patch.

Eli> It compiles and links okay, thanks.  Do you want me to test some
Eli> feature(s) to make sure the resulting binary works as expected?

Sure.  If you have dejagnu, try charset.exp.

Otherwise, any use of a string in an expression should exercise the
relevant code paths.  You could also "set target-charset" and see what
gdb thinks is available; if you have libiconv there should be lots of
output.

Tom

Re: Configuring gdb_wchar.h

[Eli Zaretskii]

> Cc: gdb-patches@sources.redhat.com
> From: Tom Tromey <tromey@redhat.com>
> Date: Tue, 14 Apr 2009 10:31:13 -0600
> 
> If you have dejagnu, try charset.exp.

I don't (dejagnu doesn't work on DOS), but I can easily run the same
test manually.

> Otherwise, any use of a string in an expression should exercise the
> relevant code paths.  You could also "set target-charset" and see what
> gdb thinks is available; if you have libiconv there should be lots of
> output.

Something's definitely wrong, because "set target-charset TAB" just
beeps, and if I type RET, it says:

    (gdb) set target-charset
    Requires an argument. Valid arguments are .

So it thinks there are no charsets available.  Maybe the line marked
below, shown as part of GDB initialization, is a hint to the trouble:

       D:\gdb-68.410\gdb>gdb ./gdb.exe
 >>>>  Usage: iconv [--binary] [-f fromcode] [-t tocode] [file ...]
       GNU gdb (GDB) 6.8.50.20090410
       Copyright (C) 2009 Free Software Foundation, Inc.

I will look into it.  Thanks for the leads.

Re: Configuring gdb_wchar.h

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

Eli> So it thinks there are no charsets available.  Maybe the line marked
Eli> below, shown as part of GDB initialization, is a hint to the trouble:

Yeah.

Eli>        D:\gdb-68.410\gdb>gdb ./gdb.exe
>>>>> Usage: iconv [--binary] [-f fromcode] [-t tocode] [file ...]
Eli>        GNU gdb (GDB) 6.8.50.20090410
Eli>        Copyright (C) 2009 Free Software Foundation, Inc.

If you have libiconv, I would expect configure to find iconvlist, and
thus not compile this code in at all.

I guess that didn't happen, which points to some configure oversight.

Also I see that the popen path ought to redirect stderr and also test
the result of pclose.  I'll deal with that.

Tom

Re: Configuring gdb_wchar.h

[Eli Zaretskii]

> Cc: gdb-patches@sources.redhat.com
> From: Tom Tromey <tromey@redhat.com>
> Date: Tue, 14 Apr 2009 11:41:57 -0600
> 
> Eli>        D:\gdb-68.410\gdb>gdb ./gdb.exe
> >>>>> Usage: iconv [--binary] [-f fromcode] [-t tocode] [file ...]
> Eli>        GNU gdb (GDB) 6.8.50.20090410
> Eli>        Copyright (C) 2009 Free Software Foundation, Inc.
> 
> If you have libiconv, I would expect configure to find iconvlist, and
> thus not compile this code in at all.

"nm -A" shows no iconvlist in libiconv that I have installed.  Maybe I
have a version that's too old?

    D:\gdb-68.410\gdb>iconv --version
    iconv (GNU libiconv 1.7)
    Copyright (C) 2000-2001 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.  There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
    Written by Bruno Haible.

I see that a port of libiconv 1.9.2 is available; should I upgrade, or
do you want me to hold until the configury problems with this old
version are resolved?

Re: Configuring gdb_wchar.h

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

Eli> "nm -A" shows no iconvlist in libiconv that I have installed.  Maybe I
Eli> have a version that's too old?

Could be.  I see that the -l option wasn't added to libiconv's "iconv"
until 1.8.  So, that explains the error message.

According to ChangeLog, iconvlist was added 2002-01-13, a few months
before the 1.8 release.

1.8 was released in 2002.  That seems rather old to me; but if users
are really still using it, I suppose we ought to deal with it.

Eli> I see that a port of libiconv 1.9.2 is available; should I upgrade, or
Eli> do you want me to hold until the configury problems with this old
Eli> version are resolved?

I think I have an understanding of the failure modes and I can set up
environments here to test them.  So, I think it is up to you.

I'm thinking of changing the startup code to use pexecute rather than
popen.  Does pexecute work on DJGPP?

Tom

Re: Configuring gdb_wchar.h

[Eli Zaretskii]

> Cc: gdb-patches@sources.redhat.com
> From: Tom Tromey <tromey@redhat.com>
> Date: Tue, 14 Apr 2009 12:15:00 -0600
> 
> I'm thinking of changing the startup code to use pexecute rather than
> popen.  Does pexecute work on DJGPP?

There's no pexecute in the DJGPP library, but there's one in
libiberty, and it supports DJGPP as well (see pex-djgpp.c).

Re: Configuring gdb_wchar.h

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

Eli> There's no pexecute in the DJGPP library, but there's one in
Eli> libiberty, and it supports DJGPP as well (see pex-djgpp.c).

Thanks, somehow I missed that file when I looked.

Here's an updated patch that changes charset.c to use pexecute and to
detect errors.  It also adds parsing for libiconv-style "iconv -l"
output.

I tried this with the glibc iconv, libiconv's iconv, and a phony iconv
that prints garbage and exits with an error.

If you want to give it a try, to make sure it still builds on DJGPP,
that would be nice.  If it works for you I will check it in.

Tom

2009-04-14  Tom Tromey  <tromey@redhat.com>

	* c-lang.c (c_emit_char): Use INTERMEDIATE_ENCODING.
	(c_printstr): Likewise.
	* charset.c: Include gdb_wait.h.
	(make_wchar_iterator): Use INTERMEDIATE_ENCODING.
	(find_charset_names): Use pexecute.  Handle libiconv's output.
	Detect errors.
	(_initialize_charset): Use xstrdup.
	* gdb_wchar.h: Check HAVE_BTOWC.  Split PHONY_ICONV and wchar
	cases.
	(INTERMEDIATE_ENCODING): New define.
	* configure, config.in: Rebuild.
	* configure.ac: Check for btowc.

diff --git a/gdb/c-lang.c b/gdb/c-lang.c
index 0c9e4f8..139d219 100644
--- a/gdb/c-lang.c
+++ b/gdb/c-lang.c
@@ -296,7 +296,7 @@ c_emit_char (int c, struct type *type, struct ui_file *stream, int quoter)
   obstack_init (&output);
   make_cleanup_obstack_free (&output);
 
-  convert_between_encodings ("wchar_t", host_charset (),
+  convert_between_encodings (INTERMEDIATE_ENCODING, host_charset (),
 			     obstack_base (&wchar_buf),
 			     obstack_object_size (&wchar_buf),
 			     1, &output, translit_char);
@@ -562,7 +562,7 @@ c_printstr (struct ui_file *stream, struct type *type, const gdb_byte *string,
   obstack_init (&output);
   make_cleanup_obstack_free (&output);
 
-  convert_between_encodings ("wchar_t", host_charset (),
+  convert_between_encodings (INTERMEDIATE_ENCODING, host_charset (),
 			     obstack_base (&wchar_buf),
 			     obstack_object_size (&wchar_buf),
 			     1, &output, translit_char);
diff --git a/gdb/charset.c b/gdb/charset.c
index 14862e7..d6e2b11 100644
--- a/gdb/charset.c
+++ b/gdb/charset.c
@@ -22,6 +22,7 @@
 #include "gdbcmd.h"
 #include "gdb_assert.h"
 #include "gdb_obstack.h"
+#include "gdb_wait.h"
 #include "charset-list.h"
 #include "vec.h"
 
@@ -527,7 +528,7 @@ make_wchar_iterator (const gdb_byte *input, size_t bytes, const char *charset,
   struct wchar_iterator *result;
   iconv_t desc;
 
-  desc = iconv_open ("wchar_t", charset);
+  desc = iconv_open (INTERMEDIATE_ENCODING, charset);
   if (desc == (iconv_t) -1)
     perror_with_name ("Converting character sets");
 
@@ -698,35 +699,92 @@ find_charset_names (void)
 static void
 find_charset_names (void)
 {
-  FILE *in;
+  struct pex_obj *child;
+  char *args[3];
+  int err, status;
+  int fail = 1;
+
+  child = pex_init (0, "iconv", NULL);
+
+  args[0] = "iconv";
+  args[1] = "-l";
+  args[2] = NULL;
+  /* Note that we simply ignore errors here.  */
+  if (!pex_run (child, PEX_SEARCH | PEX_STDERR_TO_STDOUT, "iconv",
+		args, NULL, NULL, &err))
+    {
+      FILE *in = pex_read_output (child, 0);
+
+      /* POSIX says that iconv -l uses an unspecified format.  We
+	 parse the glibc and libiconv formats; feel free to add others
+	 as needed.  */
+      while (!feof (in))
+	{
+	  /* The size of buf is chosen arbitrarily.  */
+	  char buf[1024];
+	  char *start, *r;
+	  int len, keep_going;
+
+	  r = fgets (buf, sizeof (buf), in);
+	  if (!r)
+	    break;
+	  len = strlen (r);
+	  if (len <= 3)
+	    continue;
+	  /* Strip off the newline.  */
+	  --len;
+	  /* Strip off one or two '/'s.  glibc will print lines like
+	     "8859_7//", but also "10646-1:1993/UCS4/".  */
+	  if (buf[len - 1] == '/')
+	    --len;
+	  if (buf[len - 1] == '/')
+	    --len;
+	  buf[len] = '\0';
+
+	  /* libiconv will print multiple entries per line, separated
+	     by spaces.  */
+	  start = buf;
+	  while (1)
+	    {
+	      int keep_going;
+	      char *p;
+
+	      /* Find the next space, or end-of-line.  */
+	      for (p = start; *p && *p != ' '; ++p)
+		;
+	      /* Ignore an empty result.  */
+	      if (p == start)
+		break;
+	      keep_going = *p;
+	      *p = '\0';
+	      VEC_safe_push (char_ptr, charsets, xstrdup (start));
+	      if (!keep_going)
+		break;
+	      /* Skip any extra spaces.  */
+	      for (start = p + 1; *start && *start == ' '; ++start)
+		;
+	    }
+	}
 
-  in = popen ("iconv -l", "r");
-  /* It is ok to ignore errors; we'll fall back on a default.  */
-  if (!in)
-    return;
+      if (pex_get_status (child, 1, &status)
+	  && WIFEXITED (status) && !WEXITSTATUS (status))
+	fail = 0;
 
-  /* POSIX says that iconv -l uses an unspecified format.  We parse
-     the glibc format; feel free to add others as needed.  */
-  while (!feof (in))
-    {
-      /* The size of buf is chosen arbitrarily.  A character set name
-	 longer than this would not be very nice.  */
-      char buf[80];
-      int len;
-      char *r = fgets (buf, sizeof (buf), in);
-      if (!r)
-	break;
-      len = strlen (r);
-      if (len <= 3)
-	continue;
-      if (buf[len - 2] == '/' && buf[len - 3] == '/')
-	buf[len - 3] = '\0';
-      VEC_safe_push (char_ptr, charsets, xstrdup (buf));
     }
 
-  pclose (in);
+  pex_free (child);
 
-  VEC_safe_push (char_ptr, charsets, NULL);
+  if (fail)
+    {
+      /* Some error occurred, so drop the vector.  */
+      int ix;
+      char *elt;
+      for (ix = 0; VEC_iterate (char_ptr, charsets, ix, elt); ++ix)
+	xfree (elt);
+      VEC_truncate (char_ptr, charsets, 0);
+    }
+  else
+    VEC_safe_push (char_ptr, charsets, NULL);
 }
 
 #endif /* HAVE_ICONVLIST || HAVE_LIBICONVLIST */
@@ -739,7 +797,7 @@ _initialize_charset (void)
 
   /* The first element is always "auto"; then we skip it for the
      commands where it is not allowed.  */
-  VEC_safe_push (char_ptr, charsets, "auto");
+  VEC_safe_push (char_ptr, charsets, xstrdup ("auto"));
   find_charset_names ();
 
   if (VEC_length (char_ptr, charsets) > 1)
diff --git a/gdb/config.in b/gdb/config.in
index 0d5effa..ab0c840 100644
--- a/gdb/config.in
+++ b/gdb/config.in
@@ -70,6 +70,9 @@
 /* Define to 1 if you have the <bp-sym.h> header file. */
 #undef HAVE_BP_SYM_H
 
+/* Define to 1 if you have the `btowc' function. */
+#undef HAVE_BTOWC
+
 /* Define to 1 if you have the `canonicalize_file_name' function. */
 #undef HAVE_CANONICALIZE_FILE_NAME
 
diff --git a/gdb/configure b/gdb/configure
index 51f35f5..e06a451 100755
--- a/gdb/configure
+++ b/gdb/configure
@@ -15776,10 +15776,11 @@ fi
 
 
 
+
 for ac_func in canonicalize_file_name realpath getrusage getuid \
                 getgid poll pread64 sbrk setpgid setpgrp setsid \
 		sigaction sigprocmask sigsetmask socketpair syscall \
-		ttrace wborder setlocale iconvlist libiconvlist
+		ttrace wborder setlocale iconvlist libiconvlist btowc
 do
 as_ac_var=`echo "ac_cv_func_$ac_func" | $as_tr_sh`
 echo "$as_me:$LINENO: checking for $ac_func" >&5
diff --git a/gdb/configure.ac b/gdb/configure.ac
index 821dffe..88bd8a6 100644
--- a/gdb/configure.ac
+++ b/gdb/configure.ac
@@ -796,7 +796,7 @@ AC_FUNC_VFORK
 AC_CHECK_FUNCS([canonicalize_file_name realpath getrusage getuid \
                 getgid poll pread64 sbrk setpgid setpgrp setsid \
 		sigaction sigprocmask sigsetmask socketpair syscall \
-		ttrace wborder setlocale iconvlist libiconvlist])
+		ttrace wborder setlocale iconvlist libiconvlist btowc])
 AM_LANGINFO_CODESET
 
 # Check the return and argument types of ptrace.  No canned test for
diff --git a/gdb/gdb_wchar.h b/gdb/gdb_wchar.h
index 583140e..07a6c87 100644
--- a/gdb/gdb_wchar.h
+++ b/gdb/gdb_wchar.h
@@ -19,13 +19,36 @@
 #ifndef GDB_WCHAR_H
 #define GDB_WCHAR_H
 
-/* If this host has wchar_t and if iconv is available (perhaps via GNU
-   libiconv), then we arrange to use those.  Otherwise, we provide a
-   phony iconv which only handles a single character set, and we
-   provide wrappers for the wchar_t functionality we use.  */
-#if defined(HAVE_ICONV) && defined(HAVE_WCHAR_H)
-
+/* We handle three different modes here.
+   
+   Capable systems have the full suite: wchar_t support and iconv
+   (perhaps via GNU libiconv).  On these machines, full functionality
+   is available.
+   
+   DJGPP is known to have libiconv but not wchar_t support.  On
+   systems like this, we use the narrow character functions.  The full
+   functionality is available to the user, but many characters (those
+   outside the narrow range) will be displayed as escapes.
+   
+   Finally, some systems do not have iconv.  Here we provide a phony
+   iconv which only handles a single character set, and we provide
+   wrappers for the wchar_t functionality we use.  */
+
+
+#define INTERMEDIATE_ENCODING "wchar_t"
+
+#if defined (HAVE_ICONV)
 #include <iconv.h>
+#else
+/* This define is used elsewhere so we don't need to duplicate the
+   same checking logic in multiple places.  */
+#define PHONY_ICONV
+#endif
+
+/* We use "btowc" as a sentinel to detect functioning wchar_t
+   support.  */
+#if defined (HAVE_ICONV) && defined (HAVE_WCHAR_H) && defined (HAVE_BTOWC)
+
 #include <wchar.h>
 #include <wctype.h>
 
@@ -53,10 +76,15 @@ typedef int gdb_wint_t;
 
 #define LCST(X) X
 
-/* This define is used elsewhere so we don't need to duplicate the
-   same checking logic in multiple places.  */
-#define PHONY_ICONV
+/* If we are using the narrow character set, we want to use the host
+   narrow encoding as our intermediate encoding.  However, if we are
+   also providing a phony iconv, we might as well just stick with
+   "wchar_t".  */
+#ifndef PHONY_ICONV
+#undef INTERMEDIATE_ENCODING
+#define INTERMEDIATE_ENCODING host_charset ()
+#endif
 
-#endif /* defined(HAVE_ICONV) && defined(HAVE_WCHAR_H) */
+#endif
 
 #endif /* GDB_WCHAR_H */

Re: Configuring gdb_wchar.h

[Eli Zaretskii]

> Cc: gdb-patches@sources.redhat.com
> From: Tom Tromey <tromey@redhat.com>
> Date: Tue, 14 Apr 2009 18:23:25 -0600
> 
> Here's an updated patch that changes charset.c to use pexecute and to
> detect errors.  It also adds parsing for libiconv-style "iconv -l"
> output.
> 
> I tried this with the glibc iconv, libiconv's iconv, and a phony iconv
> that prints garbage and exits with an error.
> 
> If you want to give it a try, to make sure it still builds on DJGPP,
> that would be nice.  If it works for you I will check it in.

It builds fine, but the result seems strange to me: GDB now lists a
long list of character sets in response to "set target-charset TAB".

What happens is that find_charset_names correctly notices that
"iconv -l" exited with a non-zero status (this is still with libiconv 1.7,
where the -l switch is not supported), but then _initialize_charset
falls back on using DEFAULT_CHARSET_NAMES, which seem to assume a
glibc-based system.  I rather expected the result to be that only a
single target charset be available.  Am I missing something?  Should
DEFAULT_CHARSET_NAMES be redefined on DJGPP to something different
from what charset-list.h defines it?

I will upgrade to a newer libiconv and try with that, once the result
for 1.7 is as expected (whatever that might be).

Thanks.

Re: Configuring gdb_wchar.h

[Eli Zaretskii]

> Date: Wed, 15 Apr 2009 13:05:29 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: gdb-patches@sources.redhat.com
> 
> What happens is that find_charset_names correctly notices that
> "iconv -l" exited with a non-zero status (this is still with libiconv 1.7,
> where the -l switch is not supported), but then _initialize_charset
> falls back on using DEFAULT_CHARSET_NAMES, which seem to assume a
> glibc-based system.

Also, these results are somewhat surprising:

    (gdb) show host-charset
    The host character set is "auto; currently UTF-8".
    (gdb) show target-charset
    The target character set is "ISO-8859-1".

This is the DJGPP port.  Is this expected?  Where are these defaults
set?

The same GDB built on GNU/Linux shows something much more plausible:

    (gdb) show host-charset
    The host character set is "auto; currently ANSI_X3.4-1968".
    (gdb) show target-charset
    The target character set is "ANSI_X3.4-1968".

GDB 6.8 shows ISO-8859-1 for both character sets, FWIW.

Re: Configuring gdb_wchar.h

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

Eli>     (gdb) show host-charset
Eli>     The host character set is "auto; currently UTF-8".
Eli>     (gdb) show target-charset
Eli>     The target character set is "ISO-8859-1".

Eli> This is the DJGPP port.  Is this expected?  Where are these defaults
Eli> set?

If a system has nl_langinfo(CODESET), then that is used.
Otherwise, we fall back on a built-in default.

Eli> GDB 6.8 shows ISO-8859-1 for both character sets, FWIW.

6.8 did no auto-detection at all and had ISO-8859-1 coded in.
I changed the default to UTF-8 because that is increasingly common.

Tom

Re: Configuring gdb_wchar.h

[Eli Zaretskii]

> Cc: gdb-patches@sources.redhat.com
> From: Tom Tromey <tromey@redhat.com>
> Date: Wed, 15 Apr 2009 09:13:53 -0600
> 
> >>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
> 
> Eli>     (gdb) show host-charset
> Eli>     The host character set is "auto; currently UTF-8".
> Eli>     (gdb) show target-charset
> Eli>     The target character set is "ISO-8859-1".
> 
> Eli> This is the DJGPP port.  Is this expected?  Where are these defaults
> Eli> set?
> 
> If a system has nl_langinfo(CODESET), then that is used.
> Otherwise, we fall back on a built-in default.

Would it make sense to tailor the default on specific platforms?
DJGPP does not have `nl_langinfo', and will probably never support any
character set except ASCII and the current DOS codepage.

> Eli> GDB 6.8 shows ISO-8859-1 for both character sets, FWIW.
> 
> 6.8 did no auto-detection at all and had ISO-8859-1 coded in.
> I changed the default to UTF-8 because that is increasingly common.

We need to document all that, I think.  I will give it a shot if no
one beats me to it.

Thanks.

Re: Configuring gdb_wchar.h

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

Tom> If a system has nl_langinfo(CODESET), then that is used.
Tom> Otherwise, we fall back on a built-in default.

Eli> Would it make sense to tailor the default on specific platforms?
Eli> DJGPP does not have `nl_langinfo', and will probably never support any
Eli> character set except ASCII and the current DOS codepage.

Yeah, it would make sense to be able to auto-select the host charset.
If there is a way to detect the current DOS codepage, and if that is
equivalent to the notion of the host charset (I don't know), then we
could put the needed code into _initialize_charset.

Eli> GDB 6.8 shows ISO-8859-1 for both character sets, FWIW.

Tom> 6.8 did no auto-detection at all and had ISO-8859-1 coded in.
Tom> I changed the default to UTF-8 because that is increasingly common.

Eli> We need to document all that, I think.  I will give it a shot if no
Eli> one beats me to it.

How about the appended?

Tom

2009-04-15  Tom Tromey  <tromey@redhat.com>

	* gdb.texinfo (Character Sets): Document default character set.

diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index 5269dfc..ebba32f 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -7998,7 +7998,9 @@ Set the current host character set to @var{charset}.
 
 By default, @value{GDBN} uses a host character set appropriate to the
 system it is running on; you can override that default using the
-@code{set host-charset} command.
+@code{set host-charset} command.  On some systems, @value{GDBN} cannot
+automatically determine the appropriate host character set.  In this
+case, @value{GDBN} uses @samp{UTF-8}.
 
 @value{GDBN} can only use certain character sets as its host character
 set.  If you type @kbd{@w{set target-charset @key{TAB}@key{TAB}}},

Re: Configuring gdb_wchar.h

[Eli Zaretskii]

> Cc: gdb-patches@sources.redhat.com
> From: Tom Tromey <tromey@redhat.com>
> Date: Wed, 15 Apr 2009 12:03:57 -0600
> 
> If there is a way to detect the current DOS codepage, and if that is
> equivalent to the notion of the host charset (I don't know), then we
> could put the needed code into _initialize_charset.

There's a system call to do that, yes.  Perhaps I should just write a
limited emulation of nl_langinfo which will do the job.  That would
avoid ugly system-dependent code in charset.c.  WDYT?

> Eli> GDB 6.8 shows ISO-8859-1 for both character sets, FWIW.
> 
> Tom> 6.8 did no auto-detection at all and had ISO-8859-1 coded in.
> Tom> I changed the default to UTF-8 because that is increasingly common.
> 
> Eli> We need to document all that, I think.  I will give it a shot if no
> Eli> one beats me to it.
> 
> How about the appended?

Fine with me, thanks.

Re: Configuring gdb_wchar.h

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

Tom> If there is a way to detect the current DOS codepage, and if that is
Tom> equivalent to the notion of the host charset (I don't know), then we
Tom> could put the needed code into _initialize_charset.

Eli> There's a system call to do that, yes.  Perhaps I should just write a
Eli> limited emulation of nl_langinfo which will do the job.  That would
Eli> avoid ugly system-dependent code in charset.c.  WDYT?

Either way is fine by me.

libiconv also includes "libcharset", which includes a locale_charset
function to do this.  So, we could use that if it is available.  I
couldn't immediately tell when that was added to the libiconv package.

Tom

Re: Configuring gdb_wchar.h

[Eli Zaretskii]

> Cc: gdb-patches@sources.redhat.com
> From: Tom Tromey <tromey@redhat.com>
> Date: Wed, 15 Apr 2009 13:52:50 -0600
> 
> >>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
> 
> Tom> If there is a way to detect the current DOS codepage, and if that is
> Tom> equivalent to the notion of the host charset (I don't know), then we
> Tom> could put the needed code into _initialize_charset.
> 
> Eli> There's a system call to do that, yes.  Perhaps I should just write a
> Eli> limited emulation of nl_langinfo which will do the job.  That would
> Eli> avoid ugly system-dependent code in charset.c.  WDYT?
> 
> Either way is fine by me.
> 
> libiconv also includes "libcharset", which includes a locale_charset
> function to do this.  So, we could use that if it is available.  I
> couldn't immediately tell when that was added to the libiconv package.

OK, I will look into both possibilities and see what I come up with.

Thanks.

Re: Configuring gdb_wchar.h

[Eli Zaretskii]

> Date: Wed, 15 Apr 2009 23:17:42 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: gdb-patches@sources.redhat.com
> 
> > Cc: gdb-patches@sources.redhat.com
> > From: Tom Tromey <tromey@redhat.com>
> > Date: Wed, 15 Apr 2009 13:52:50 -0600
> > 
> > >>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
> > 
> > Tom> If there is a way to detect the current DOS codepage, and if that is
> > Tom> equivalent to the notion of the host charset (I don't know), then we
> > Tom> could put the needed code into _initialize_charset.
> > 
> > Eli> There's a system call to do that, yes.  Perhaps I should just write a
> > Eli> limited emulation of nl_langinfo which will do the job.  That would
> > Eli> avoid ugly system-dependent code in charset.c.  WDYT?
> > 
> > Either way is fine by me.
> > 
> > libiconv also includes "libcharset", which includes a locale_charset
> > function to do this.  So, we could use that if it is available.  I
> > couldn't immediately tell when that was added to the libiconv package.
> 
> OK, I will look into both possibilities and see what I come up with.

Here's what I finally ended up with.  I decided to write an emulation
of nl_langinfo, instead of using locale_charset, because of these
reasons:

  . The DJGPP port of locale_charset returns an empty string or
    "ASCII" (depending on the version), if none of the environment
    variables LC_ALL, LC_TYPE, or LANG is defined.  It ought to fall
    back on the DOS codepage, but it doesn't.

  . Using locale_charset needs a change in the configury (to link
    against libcharset), which I wanted to avoid.  If GDB ends up
    using locale_charset, and thus the necessary configury stuff will
    be added anyway, I might reconsider (e.g., I could include a call
    to locale_charset inside the emulated nl_langinfo).

  . If the appropriate LC_* variables are set in the environment, then
    using locale_charset is better than just having an nl_langinfo
    that always returns the system codepage, but for GDB, this is only
    marginally better, and can easily be fixed by a simple command or
    a line in gdb.ini.

If there are no objections, I will commit the patch below.

Thanks.

2009-04-17  Eli Zaretskii  <eliz@gnu.org>

	* config/djgpp/config.sed (am_cv_langinfo_codeset)
	(bash_cv_langinfo_codeset, ac_cv_header_nl_types_h): Set to "yes"
	in all configure scripts that define ac_cv_env_CPP_value.

	* go32-nat.c (dos_codepage, nl_langinfo): New functions.
	Include langinfo.h.

	* config/djgpp/nl_types.h: New file.

	* config/djgpp/langinfo.h: New file.

	* config/i386/go32.mh (MH_CFLAGS): Add $(srcdir)/config/djgpp.


--- go32-nat.c~1	2009-04-11 19:55:40.984375000 +0300
+++ go32-nat.c	2009-04-18 12:09:08.503000000 +0300
@@ -53,6 +53,8 @@
 #include <debug/redir.h>
 #endif
 
+#include <langinfo.h>
+
 #if __DJGPP_MINOR__ < 3
 /* This code will be provided from DJGPP 2.03 on. Until then I code it
    here */
@@ -938,6 +940,47 @@
   strcpy (gdbinit, "gdb.ini");
 }
 
+/* Return the current DOS codepage number.  */
+static int
+dos_codepage (void)
+{
+  __dpmi_regs regs;
+
+  regs.x.ax = 0x6601;
+  __dpmi_int (0x21, &regs);
+  if (!(regs.x.flags & 1))
+    return regs.x.bx & 0xffff;
+  else
+    return 437;	/* default */
+}
+
+/* Limited emulation of `nl_langinfo', for charset.c.  */
+char *
+nl_langinfo (nl_item item)
+{
+  char *retval;
+
+  switch (item)
+    {
+      case CODESET:
+	{
+	  /* 8 is enough for SHORT_MAX + "CP" + null.  */
+	  char buf[8];
+	  int blen = sizeof (buf);
+	  int needed = snprintf (buf, blen, "CP%d", dos_codepage ());
+
+	  if (needed > blen)	/* should never happen */
+	    buf[0] = 0;
+	  retval = xstrdup (buf);
+	}
+	break;
+      default:
+	retval = xstrdup ("");
+	break;
+    }
+  return retval;
+}
+
 unsigned short windows_major, windows_minor;
 
 /* Compute the version Windows reports via Int 2Fh/AX=1600h.  */

--- config/djgpp/config.s~1	2009-04-10 17:01:57.221500000 +0300
+++ config/djgpp/config.sed	2009-04-18 10:45:48.393625000 +0300
@@ -25,6 +25,12 @@
   s,config\\.h\\.in,config.h-in,g;t t\
   s,po2tbl\\.sed\\.in,po2tblsed.in,g;t t
 
+# We have an emulation of nl_langinfo in go32-nat.c that supports CODESET.
+/^ac_cv_env_CPP_value=/a\
+am_cv_langinfo_codeset=yes\
+bash_cv_langinfo_codeset=yes\
+ac_cv_header_nl_types_h=yes
+
 # Prevent splitting of config.status substitutions, because that
 # might break multi-line sed commands.
 /ac_max_sed_lines=[0-9]/s,=.*$,=`sed -n "$=" $tmp/subs.sed`,

--- /dev/null	1970-01-01 02:00:00.000000000 +0200
+++ config/djgpp/nl_types.h	2009-04-17 15:54:34.440500000 +0300
@@ -0,0 +1,25 @@
+/* nl_types.h for DJGPP.
+   Copyright (C) 2009 Free Software Foundation, Inc.
+   Written by Eli Zaretskii.
+
+   This file is part of GDB.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
+
+#ifndef _NL_TYPES_H
+#define _NL_TYPES_H
+
+typedef int nl_item;
+
+#endif	/* _NL_TYPES_H */

--- /dev/null	1970-01-01 02:00:00.000000000 +0200
+++ config/djgpp/langinfo.h	2009-04-17 15:54:43.081125000 +0300
@@ -0,0 +1,35 @@
+/* langinfo.h file for DJGPP.
+   Copyright (C) 2009 Free Software Foundation, Inc.
+   Written by Eli Zaretskii.
+
+   This file is part of GDB.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
+
+#ifndef _LANGINFO_H
+#define _LANGINFO_H
+
+#include <nl_types.h>
+
+enum {
+  CODESET,
+  /* Number of enumerated values.  */
+  _NL_NUM
+};
+
+#define CODESET CODESET
+
+extern char *nl_langinfo (nl_item);
+
+#endif /* _LANGINFO_H */

--- config/i386/go32.m~0	2005-05-14 16:13:23.000000000 +0300
+++ config/i386/go32.mh	2009-04-17 14:47:12.393625000 +0300
@@ -1,5 +1,7 @@
 # Host: Intel x86 running DJGPP
-MH_CFLAGS= 
+
+# We include several header files from config/djgpp
+MH_CFLAGS= -I$(srcdir)/config/djgpp
 
 NAT_FILE= nm-go32.h
 NATDEPFILES= go32-nat.o i386-nat.o

Re: Configuring gdb_wchar.h

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

Eli> Here's what I finally ended up with.  I decided to write an emulation
Eli> of nl_langinfo, instead of using locale_charset, because of these
Eli> reasons:

[...]

Eli> If there are no objections, I will commit the patch below.

Looks reasonable to me.

Tom

Re: Configuring gdb_wchar.h

[Eli Zaretskii]

> Cc: gdb-patches@sources.redhat.com
> From: Tom Tromey <tromey@redhat.com>
> Date: Sat, 18 Apr 2009 11:27:56 -0600
> 
> >>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
> 
> Eli> Here's what I finally ended up with.  I decided to write an emulation
> Eli> of nl_langinfo, instead of using locale_charset, because of these
> Eli> reasons:
> 
> [...]
> 
> Eli> If there are no objections, I will commit the patch below.
> 
> Looks reasonable to me.

Thanks, committed.

Re: Configuring gdb_wchar.h

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

Eli> It builds fine, but the result seems strange to me: GDB now lists a
Eli> long list of character sets in response to "set target-charset TAB".

Eli> What happens is that find_charset_names correctly notices that
Eli> "iconv -l" exited with a non-zero status (this is still with libiconv 1.7,
Eli> where the -l switch is not supported), but then _initialize_charset
Eli> falls back on using DEFAULT_CHARSET_NAMES, which seem to assume a
Eli> glibc-based system.  I rather expected the result to be that only a
Eli> single target charset be available.  Am I missing something?  Should
Eli> DEFAULT_CHARSET_NAMES be redefined on DJGPP to something different
Eli> from what charset-list.h defines it?

Your situation is somewhat odd.  You have a working iconv but no way
to get a list of available character sets.  This ought to be a rare
setup.

In this case I chose to make gdb fall back on a fairly large built-in
list.  If you try pick a charset which your iconv cannot handle, gdb
should give an error.

Eli> I will upgrade to a newer libiconv and try with that, once the result
Eli> for 1.7 is as expected (whatever that might be).

I think the current result is as good as any other.

Tom

Re: Configuring gdb_wchar.h

[Pedro Alves]

On Wednesday 15 April 2009 16:08:13, Tom Tromey wrote:
> In this case I chose to make gdb fall back on a fairly large built-in
> list.  If you try pick a charset which your iconv cannot handle, gdb
> should give an error.

Could gdb probe to see if they work at all?  Is that feasible?
If it is, would it be too slow?

-- 
Pedro Alves

Re: Configuring gdb_wchar.h

[Tom Tromey]

>>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:

Pedro> Could gdb probe to see if they work at all?  Is that feasible?
Pedro> If it is, would it be too slow?

You can't probe to see if a single one works -- only pairs of them.
That's the real reason we do this checking so late.

There may be other situations in which the current logic fails and
cannot be made to work.  The failing case would be something like a
host that has a native iconv but no way at all to list the character
sets.  But even here, installing libiconv will work.

Tom

Re: Configuring gdb_wchar.h

[Eli Zaretskii]

> Cc: gdb-patches@sources.redhat.com
> From: Tom Tromey <tromey@redhat.com>
> Date: Wed, 15 Apr 2009 09:08:13 -0600
> 
> Your situation is somewhat odd.  You have a working iconv but no way
> to get a list of available character sets.  This ought to be a rare
> setup.
> 
> In this case I chose to make gdb fall back on a fairly large built-in
> list.  If you try pick a charset which your iconv cannot handle, gdb
> should give an error.

Right, that does work as you say:

    (gdb) set target-charset CP839
    Undefined item: "CP839".

Although I find it odd that GDB insists on the charsets to be in
UPPERCASE.  This is okay:

    (gdb) set target-charset ISO-8859-1

but this is not:

    (gdb) set target-charset iso-8859-1
    Undefined item: "iso-8859-1".

> Eli> I will upgrade to a newer libiconv and try with that, once the result
> Eli> for 1.7 is as expected (whatever that might be).
> 
> I think the current result is as good as any other.

OK, then on to upgrading libiconv.

Thanks.

Re: Configuring gdb_wchar.h

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

Eli> Although I find it odd that GDB insists on the charsets to be in
Eli> UPPERCASE.

I suppose we could fix this, either by adding a new kind of
case-insensitive var_enum, or by adding lowercase variants of all the
character set names to the list.

I don't really mind the current approach.  But, if other folks want
this, I can implement something.

Tom

Re: Configuring gdb_wchar.h

[Tom Tromey]

>>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes:

Tom> Here's an updated patch that changes charset.c to use pexecute and to
Tom> detect errors.  It also adds parsing for libiconv-style "iconv -l"
Tom> output.

Tom> I tried this with the glibc iconv, libiconv's iconv, and a phony iconv
Tom> that prints garbage and exits with an error.

Tom> If you want to give it a try, to make sure it still builds on DJGPP,
Tom> that would be nice.  If it works for you I will check it in.

I'm checking this in now.  Thanks for trying it out.

Tom

Re: Configuring gdb_wchar.h

[Eli Zaretskii]

> Cc: gdb-patches@sources.redhat.com
> From: Tom Tromey <tromey@redhat.com>
> Date: Tue, 14 Apr 2009 10:31:13 -0600
> 
> >>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
> 
> Tom> Please try the appended patch.
> 
> Eli> It compiles and links okay, thanks.  Do you want me to test some
> Eli> feature(s) to make sure the resulting binary works as expected?
> 
> Sure.  If you have dejagnu, try charset.exp.

I ran some of the tests in charset.exp by hand, and I see some
potential issues.

For example, when I set the host charset to UTF-8 and the target
charset to EBCDIC-US, I get an error message:

    Cannot convert between character sets `EBCDIC-US' and `UTF-8'

Is this expected?  Is this again a consequence of the list of charsets
not coming from libiconv, but from the default?

Also, this result seems to be different from what charsets.exp
expects:

    Breakpoint 1, main () at charset.c:173
    173        }
    (gdb) set host-charset ASCII
    (gdb) set target-charset ISO-8859-1
    (gdb) print iso_8859_1_string[69]
    $2 = -94 '\242'
    (gdb) print iso_8859_1_string+70
    $3 = 0xbdb6 "\21"
    (gdb) print iso_8859_1_string[70]
    $4 = 17 '\21'

Perhaps I misunderstood, but this part of the test seems to expect
something different, at least for the second and third print commands:

    # Test handling of characters in the target charset which
    # can't be translated into the host charset.
    if {! [string compare $target_charset iso-8859-1]} {
        gdb_test "print iso_8859_1_string\[69\]" \
                 " = \[0-9-\]+ '\\\\242'" \
                 "print character with no equivalent in host character set"
        gdb_test "print iso_8859_1_string + 70" \
                 " = ${hex} \"\\\\242.*\"" \
                 "print string with no equivalent in host character set"
    }

I also noticed that on a GNU/Linux system, "set target-charset TAB"
shows the list of possible charsets with a ^J character at the end of
each line.

Re: Configuring gdb_wchar.h

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

Eli> For example, when I set the host charset to UTF-8 and the target
Eli> charset to EBCDIC-US, I get an error message:
Eli>     Cannot convert between character sets `EBCDIC-US' and `UTF-8'
Eli> Is this expected?  Is this again a consequence of the list of charsets
Eli> not coming from libiconv, but from the default?

Probably.

Eli> Also, this result seems to be different from what charsets.exp
Eli> expects:

I'll look into it next week.

Eli> I also noticed that on a GNU/Linux system, "set target-charset TAB"
Eli> shows the list of possible charsets with a ^J character at the end of
Eli> each line.

This works fine for me.  Make sure you have the pexecute patch in your
tree.

Tom

Re: Configuring gdb_wchar.h

[Eli Zaretskii]

> Cc: gdb-patches@sources.redhat.com
> From: Tom Tromey <tromey@redhat.com>
> Date: Sat, 18 Apr 2009 11:33:15 -0600
> 
> Eli> I also noticed that on a GNU/Linux system, "set target-charset TAB"
> Eli> shows the list of possible charsets with a ^J character at the end of
> Eli> each line.
> 
> This works fine for me.  Make sure you have the pexecute patch in your
> tree.

Right, that tree wasn't patched.

Thanks.