* Your INTERMEDIATE_ENCODING patch for Solaris @ 2010-07-31 16:25 Kazu Hirata 2010-08-05 18:40 ` Tom Tromey 0 siblings, 1 reply; 40+ messages in thread From: Kazu Hirata @ 2010-07-31 16:25 UTC (permalink / raw) To: tromey; +Cc: gdb-patches Hi Tom, We've been using a version of your patch posted at: http://sourceware.org/ml/gdb-patches/2009-07/msg00434.html except that we use #ifdef __sun__ rather than #ifdef __STDC_ISO_10646__ to special case for Solaris. As Andrew replied to your message above, __STDC_ISO_10646__ is not defined on Solaris. Could we use __sun__ instead? Or if that's not enough, we could try something like: #if defined(__sun__) || defined(__STDC_ISO_10646__) Thoughts? Thanks in advance, Kazu Hirata ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Your INTERMEDIATE_ENCODING patch for Solaris 2010-07-31 16:25 Your INTERMEDIATE_ENCODING patch for Solaris Kazu Hirata @ 2010-08-05 18:40 ` Tom Tromey 2010-08-10 20:28 ` Daniel Jacobowitz 2010-08-17 18:06 ` Tom Tromey 0 siblings, 2 replies; 40+ messages in thread From: Tom Tromey @ 2010-08-05 18:40 UTC (permalink / raw) To: Kazu Hirata; +Cc: gdb-patches >>>>> "Kazu" == Kazu Hirata <kazu@codesourcery.com> writes: Kazu> We've been using a version of your patch posted at: Kazu> http://sourceware.org/ml/gdb-patches/2009-07/msg00434.html Kazu> except that we use Kazu> #ifdef __sun__ Kazu> rather than Kazu> #ifdef __STDC_ISO_10646__ Kazu> to special case for Solaris. Kazu> As Andrew replied to your message above, __STDC_ISO_10646__ is not Kazu> defined on Solaris. Could we use __sun__ instead? I am not a Solaris expert, but some digging through the online OpenSolaris libc sources a few months ago convinced me that the Solaris wchar_t is in fact not UCS-4. If that is true, then this patch would be incorrect. My recollection is that if your locale's encoding was a stateful one, then the Solaris wchar_t held the state in the high bits and the character in the low bits; so I suppose this would be one way to try to test to verify this hypothesis. A better way would be to check out the libc and read through it oneself. This particular problem has come up multiple times. I am not completely sure what to do about it, but my current inclination is to change gdb so that most hosts fall back to PHONY_ICONV, with exceptions for libiconv and for Linux. This will at least have gdb default to working, and is also attractive because I have some hope of actually testing it. Tom ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Your INTERMEDIATE_ENCODING patch for Solaris 2010-08-05 18:40 ` Tom Tromey @ 2010-08-10 20:28 ` Daniel Jacobowitz 2010-08-17 18:06 ` Tom Tromey 1 sibling, 0 replies; 40+ messages in thread From: Daniel Jacobowitz @ 2010-08-10 20:28 UTC (permalink / raw) To: Tom Tromey; +Cc: Kazu Hirata, gdb-patches On Thu, Aug 05, 2010 at 12:40:35PM -0600, Tom Tromey wrote: > This particular problem has come up multiple times. I am not completely > sure what to do about it, but my current inclination is to change gdb so > that most hosts fall back to PHONY_ICONV, with exceptions for libiconv > and for Linux. This will at least have gdb default to working, and is > also attractive because I have some hope of actually testing it. Sounds good to me. -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Your INTERMEDIATE_ENCODING patch for Solaris 2010-08-05 18:40 ` Tom Tromey 2010-08-10 20:28 ` Daniel Jacobowitz @ 2010-08-17 18:06 ` Tom Tromey 2010-08-17 18:44 ` Joel Brobecker 1 sibling, 1 reply; 40+ messages in thread From: Tom Tromey @ 2010-08-17 18:06 UTC (permalink / raw) To: Kazu Hirata; +Cc: gdb-patches >>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes: Kazu> As Andrew replied to your message above, __STDC_ISO_10646__ is not Kazu> defined on Solaris. Could we use __sun__ instead? Tom> I am not a Solaris expert, but some digging through the online Tom> OpenSolaris libc sources a few months ago convinced me that the Solaris Tom> wchar_t is in fact not UCS-4. Tom> If that is true, then this patch would be incorrect. While looking at this more today, I found: http://defect.opensolaris.org/bz/show_bug.cgi?id=11076 Some of the comments make it clear that wchar_t != UCS-4 for Solaris. Tom> This particular problem has come up multiple times. I am not completely Tom> sure what to do about it, but my current inclination is to change gdb so Tom> that most hosts fall back to PHONY_ICONV, with exceptions for libiconv Tom> and for Linux. This will at least have gdb default to working, and is Tom> also attractive because I have some hope of actually testing it. Daniel> Sounds good to me. Here is what I am testing. If someone can try it out on Solaris, I would appreciate that. Tom b/gdb/ChangeLog: 2010-08-17 Tom Tromey <tromey@redhat.com> * gdb_wchar.h: Check HAVE_LIBICONV, __STDC_ISO_10646__. Change how INTERMEDIATE_ENCODING is defined. * configure, config.in: Rebuild. * acinclude.m4 (AM_ICONV): Define HAVE_LIBICONV. diff --git a/gdb/acinclude.m4 b/gdb/acinclude.m4 index 1942ef4..082a9bc 100644 --- a/gdb/acinclude.m4 +++ b/gdb/acinclude.m4 @@ -256,6 +256,7 @@ AC_DEFUN([AM_ICONV], LIBICONV= if test "$am_cv_lib_iconv" = yes; then LIBICONV="-liconv" + AC_DEFINE(HAVE_LIBICONV, 1, [Define if using libiconv.]) else LIBICONV_LIBDIR= LIBICONV_INCLUDE= diff --git a/gdb/config.in b/gdb/config.in index 7659181..35272a2 100644 --- a/gdb/config.in +++ b/gdb/config.in @@ -214,6 +214,9 @@ /* Define if you have the expat library. */ #undef HAVE_LIBEXPAT +/* Define if using libiconv. */ +#undef HAVE_LIBICONV + /* Define to 1 if you have the `libiconvlist' function. */ #undef HAVE_LIBICONVLIST diff --git a/gdb/configure b/gdb/configure index 485c904..852c5c1 100755 --- a/gdb/configure +++ b/gdb/configure @@ -9450,6 +9450,9 @@ $as_echo "$am_cv_func_iconv" >&6; } LIBICONV= if test "$am_cv_lib_iconv" = yes; then LIBICONV="-liconv" + +$as_echo "#define HAVE_LIBICONV 1" >>confdefs.h + else LIBICONV_LIBDIR= LIBICONV_INCLUDE= diff --git a/gdb/gdb_wchar.h b/gdb/gdb_wchar.h index fca3fe4..1ff7a1c 100644 --- a/gdb/gdb_wchar.h +++ b/gdb/gdb_wchar.h @@ -23,7 +23,11 @@ Capable systems have the full suite: wchar_t support and iconv (perhaps via GNU libiconv). On these machines, full functionality - is available. + is available. Note that full functionality is dependent on us + being able to convert from an arbitrary encoding to wchar_t. In + practice this means we look for __STDC_ISO_10646__ (where we know + the name of the wchar_t encoding) or GNU libiconv, where we can use + "wchar_t". DJGPP is known to have libiconv but not wchar_t support. On systems like this, we use the narrow character functions. The full @@ -35,8 +39,6 @@ wrappers for the wchar_t functionality we use. */ -#define INTERMEDIATE_ENCODING "wchar_t" - #if defined (HAVE_ICONV) #include <iconv.h> #else @@ -45,9 +47,11 @@ #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) +/* We use "btowc" as a sentinel to detect functioning wchar_t support. + We check for either __STDC_ISO_10646__ or libiconv in order to + ensure we can convert to and from wchar_t. */ +#if defined (HAVE_ICONV) && defined (HAVE_WCHAR_H) && defined (HAVE_BTOWC) \ + && (defined (__STDC_ISO_10646__) || defined (HAVE_LIBICONV)) #include <wchar.h> #include <wctype.h> @@ -63,6 +67,25 @@ typedef wint_t gdb_wint_t; #define LCST(X) L ## X +/* If __STDC_ISO_10646__ is defined, then the host wchar_t is UCS-4. + We exploit this fact in the hope that there are hosts that define + this but which do not support "wchar_t" as an encoding argument to + iconv_open. We put the endianness into the encoding name to avoid + hosts that emit a BOM when the unadorned name is used. */ +#if defined (__STDC_ISO_10646__) +#if WORDS_BIGENDIAN +#define INTERMEDIATE_ENCODING "UCS-4BE" +#else +#define INTERMEDIATE_ENCODING "UCS-4LE" +#endif +#elif defined (HAVE_LIBICONV) +#define INTERMEDIATE_ENCODING "wchar_t" +#else +/* This shouldn't happen, because the earlier #if should have filtered + out this case. */ +#error "Neither __STDC_ISO_10646__ nor HAVE_LIBICONV defined" +#endif + #else typedef char gdb_wchar_t; ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Your INTERMEDIATE_ENCODING patch for Solaris 2010-08-17 18:06 ` Tom Tromey @ 2010-08-17 18:44 ` Joel Brobecker 2010-08-17 19:03 ` Tom Tromey 0 siblings, 1 reply; 40+ messages in thread From: Joel Brobecker @ 2010-08-17 18:44 UTC (permalink / raw) To: Tom Tromey; +Cc: Kazu Hirata, gdb-patches > Here is what I am testing. If someone can try it out on Solaris, I > would appreciate that. > > Tom > > b/gdb/ChangeLog: > 2010-08-17 Tom Tromey <tromey@redhat.com> > > * gdb_wchar.h: Check HAVE_LIBICONV, __STDC_ISO_10646__. Change > how INTERMEDIATE_ENCODING is defined. > * configure, config.in: Rebuild. > * acinclude.m4 (AM_ICONV): Define HAVE_LIBICONV. What type of testing do you need? (I assume you need GDB to be built without GNU libiconv?) Run the testsuite before and after patch? Or something a little more specialized? -- Joel ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Your INTERMEDIATE_ENCODING patch for Solaris 2010-08-17 18:44 ` Joel Brobecker @ 2010-08-17 19:03 ` Tom Tromey 2010-08-18 10:14 ` Joel Brobecker 2010-08-18 11:52 ` Your INTERMEDIATE_ENCODING patch for Solaris Pierre Muller 0 siblings, 2 replies; 40+ messages in thread From: Tom Tromey @ 2010-08-17 19:03 UTC (permalink / raw) To: Joel Brobecker; +Cc: Kazu Hirata, gdb-patches >>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes: Joel> What type of testing do you need? (I assume you need GDB to be built Joel> without GNU libiconv?) Run the testsuite before and after patch? Or Joel> something a little more specialized? I think that without this patch, a Solaris build (without libiconv) is just pretty broken. I think even `print "string"' should fail. If not, it should be sufficient to look at the charset.exp results. Tom ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Your INTERMEDIATE_ENCODING patch for Solaris 2010-08-17 19:03 ` Tom Tromey @ 2010-08-18 10:14 ` Joel Brobecker 2010-08-18 14:43 ` Pierre Muller ` (2 more replies) 2010-08-18 11:52 ` Your INTERMEDIATE_ENCODING patch for Solaris Pierre Muller 1 sibling, 3 replies; 40+ messages in thread From: Joel Brobecker @ 2010-08-18 10:14 UTC (permalink / raw) To: Tom Tromey; +Cc: Kazu Hirata, gdb-patches > I think that without this patch, a Solaris build (without libiconv) is > just pretty broken. I think even `print "string"' should fail. I'm a little confused at the moment. `print "string"' works and I get only PASSes with one UNTESTED due to the fact that we only have 2 charsets available. Would it be because I have not configure GDB in a way that reproduces the problem? And then I did something that will bring the wrath of the NY sysadmin team because I ran the entire testsuite, which I forgot brings the machine down. So I cannot say more about the general results :-(. -- Joel ^ permalink raw reply [flat|nested] 40+ messages in thread
* RE: Your INTERMEDIATE_ENCODING patch for Solaris 2010-08-18 10:14 ` Joel Brobecker @ 2010-08-18 14:43 ` Pierre Muller 2010-08-18 14:52 ` Joel Brobecker 2010-08-18 15:44 ` Tom Tromey [not found] ` <15264.6257346079$1282142643@news.gmane.org> 2 siblings, 1 reply; 40+ messages in thread From: Pierre Muller @ 2010-08-18 14:43 UTC (permalink / raw) To: 'Joel Brobecker'; +Cc: gdb-patches Upon further investigation, I must confess that the OpenSolaris situation is a real mess: I get a working libiconv version for x86_64 solaris using CSW libiconv version 0x10D, libiconv_open with parameter 'wchar_t' and 'UTF-8' works. but on my Sparc64 test machine, libiconv is on /usr/local/lib and its version is 0x10B. This later version fails on calls to libiconv_open with 'wchar_t' and 'ASCII'. Then I discovered a difference: I has LANG environment variable set in the first (x86_64 machine) to en_US.UTF-8 so I tried to use that environment variable on the Sparc machine and, o wonder, gdb starts to work! So the Sparc iconv works if LANG is set to 'en_US.UTF-8', but fails it LANG is not set. Coming back to the x86_64 machine, I checked what happened if I removed the LANG environment variable... in that case it is still working, libiconv_open (ver 0x10D) accepts 'ASCII' to 'wchar_t' conversion, while version 0x10B seems to fail... At least that is where I am now, but it might not be the entire picture ... Pierre Muller Pascal language support maintainer for GDB ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Your INTERMEDIATE_ENCODING patch for Solaris 2010-08-18 14:43 ` Pierre Muller @ 2010-08-18 14:52 ` Joel Brobecker 2010-08-18 15:10 ` Pierre Muller 2010-08-18 15:35 ` Tom Tromey 0 siblings, 2 replies; 40+ messages in thread From: Joel Brobecker @ 2010-08-18 14:52 UTC (permalink / raw) To: Pierre Muller; +Cc: gdb-patches IMO, investing too much energy into making GDB work with a "difficult" (aka broken) libiconv is a waste of precious time. Perhaps it's time for us to cut the losses and decide that building GDB requires GNU libiconv. I was first in line asking that GDB could be built without GNU libiconv, but I can see from experience how much of a mess that is... ? -- Joel ^ permalink raw reply [flat|nested] 40+ messages in thread
* RE: Your INTERMEDIATE_ENCODING patch for Solaris 2010-08-18 14:52 ` Joel Brobecker @ 2010-08-18 15:10 ` Pierre Muller 2010-08-18 15:35 ` Tom Tromey 1 sibling, 0 replies; 40+ messages in thread From: Pierre Muller @ 2010-08-18 15:10 UTC (permalink / raw) To: 'Joel Brobecker'; +Cc: gdb-patches How can we identity that the installed library is a GNU one or not? I have no idea if the ones I tested are GNU or not. Pierre > -----Message d'origine----- > De : gdb-patches-owner@sourceware.org [mailto:gdb-patches- > owner@sourceware.org] De la part de Joel Brobecker > Envoyé : Wednesday, August 18, 2010 4:52 PM > À : Pierre Muller > Cc : gdb-patches@sourceware.org > Objet : Re: Your INTERMEDIATE_ENCODING patch for Solaris > > > IMO, investing too much energy into making GDB work with a "difficult" > (aka broken) libiconv is a waste of precious time. Perhaps it's time > for us to cut the losses and decide that building GDB requires GNU > libiconv. I was first in line asking that GDB could be built without > GNU libiconv, but I can see from experience how much of a mess that > is... > > ? > > -- > Joel ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Your INTERMEDIATE_ENCODING patch for Solaris 2010-08-18 14:52 ` Joel Brobecker 2010-08-18 15:10 ` Pierre Muller @ 2010-08-18 15:35 ` Tom Tromey 1 sibling, 0 replies; 40+ messages in thread From: Tom Tromey @ 2010-08-18 15:35 UTC (permalink / raw) To: Joel Brobecker; +Cc: Pierre Muller, gdb-patches >>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes: Joel> IMO, investing too much energy into making GDB work with a "difficult" Joel> (aka broken) libiconv is a waste of precious time. Perhaps it's time Joel> for us to cut the losses and decide that building GDB requires GNU Joel> libiconv. I was first in line asking that GDB could be built without Joel> GNU libiconv, but I can see from experience how much of a mess that is... Joel> ? I think we're ok. The hard part is already done -- all the PHONY_ICONV support code and typedefs and indirections. This last bit is just tinkering with the configury a little to get a decent result by default. FWIW, all this current change means is that Solaris users will see escape sequences more often than they might want to. Tom ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Your INTERMEDIATE_ENCODING patch for Solaris 2010-08-18 10:14 ` Joel Brobecker 2010-08-18 14:43 ` Pierre Muller @ 2010-08-18 15:44 ` Tom Tromey 2010-08-18 16:36 ` Joel Brobecker [not found] ` <15264.6257346079$1282142643@news.gmane.org> 2 siblings, 1 reply; 40+ messages in thread From: Tom Tromey @ 2010-08-18 15:44 UTC (permalink / raw) To: Joel Brobecker; +Cc: gdb-patches >>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes: Tom> I think that without this patch, a Solaris build (without libiconv) is Tom> just pretty broken. I think even `print "string"' should fail. Joel> I'm a little confused at the moment. `print "string"' works and I get Joel> only PASSes with one UNTESTED due to the fact that we only have 2 Joel> charsets available. Would it be because I have not configure GDB Joel> in a way that reproduces the problem? Did you build with libiconv? libiconv fixes all the problems -- the issue only shows up if you do a plain Solaris build. Tom ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Your INTERMEDIATE_ENCODING patch for Solaris 2010-08-18 15:44 ` Tom Tromey @ 2010-08-18 16:36 ` Joel Brobecker 2010-08-18 17:35 ` Tom Tromey 0 siblings, 1 reply; 40+ messages in thread From: Joel Brobecker @ 2010-08-18 16:36 UTC (permalink / raw) To: Tom Tromey; +Cc: gdb-patches > Did you build with libiconv? libiconv fixes all the problems -- the > issue only shows up if you do a plain Solaris build. I definitely tried building without libiconv. Looking at the difference in behavior, with GNU libiconv, I get some 350 possible charsets, whereas with the one I tested, I only have 2... ... Since Pierre managed to reproduce some of the problem and provide additional info, I'll let him do the helping. -- Joel ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Your INTERMEDIATE_ENCODING patch for Solaris 2010-08-18 16:36 ` Joel Brobecker @ 2010-08-18 17:35 ` Tom Tromey 2010-08-18 17:41 ` Joel Brobecker 0 siblings, 1 reply; 40+ messages in thread From: Tom Tromey @ 2010-08-18 17:35 UTC (permalink / raw) To: Joel Brobecker; +Cc: gdb-patches >>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes: >> Did you build with libiconv? libiconv fixes all the problems -- the >> issue only shows up if you do a plain Solaris build. Joel> I definitely tried building without libiconv. Looking at the difference Joel> in behavior, with GNU libiconv, I get some 350 possible charsets, whereas Joel> with the one I tested, I only have 2... Strange. I can't explain that. Maybe it could be dependent on the version of Solaris? Tom ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Your INTERMEDIATE_ENCODING patch for Solaris 2010-08-18 17:35 ` Tom Tromey @ 2010-08-18 17:41 ` Joel Brobecker 0 siblings, 0 replies; 40+ messages in thread From: Joel Brobecker @ 2010-08-18 17:41 UTC (permalink / raw) To: Tom Tromey; +Cc: gdb-patches > Strange. I can't explain that. Maybe it could be dependent on the > version of Solaris? It's very possible. I should have said that I was testing on 2.8, if that helps at all. -- Joel ^ permalink raw reply [flat|nested] 40+ messages in thread
[parent not found: <15264.6257346079$1282142643@news.gmane.org>]
* Re: Your INTERMEDIATE_ENCODING patch for Solaris [not found] ` <15264.6257346079$1282142643@news.gmane.org> @ 2010-08-18 16:12 ` Tom Tromey 2010-08-19 15:03 ` Pierre Muller 0 siblings, 1 reply; 40+ messages in thread From: Tom Tromey @ 2010-08-18 16:12 UTC (permalink / raw) To: Pierre Muller; +Cc: 'Joel Brobecker', gdb-patches >>>>> "Pierre" == Pierre Muller <pierre.muller@ics-cnrs.unistra.fr> writes: Pierre> Upon further investigation, I must confess that the OpenSolaris Pierre> situation is a real mess: Pierre> I get a working libiconv version for x86_64 solaris Pierre> using CSW libiconv version 0x10D, From the version number, I guess this is GNU libiconv. What happens if you don't build with libiconv, but rely instead on the iconv in the Solaris libc? Pierre> libiconv_open with parameter 'wchar_t' and 'UTF-8' works. Pierre> but on my Sparc64 test machine, libiconv is Pierre> on /usr/local/lib and its version is 0x10B. Pierre> This later version fails on calls to libiconv_open Pierre> with 'wchar_t' and 'ASCII'. Ouch, but ok. We can check _LIBICONV_VERSION >= 0x10D. This actually simplifies the patch a little; I didn't know about _LIBICONV_VERSION before. Could you try this? I also fixed the INTERMEDIATE_ENCODING problem you pointed out. Tom 2010-08-17 Tom Tromey <tromey@redhat.com> * gdb_wchar.h: Check _LIBICONV_VERSION, __STDC_ISO_10646__. Change how INTERMEDIATE_ENCODING is defined. diff --git a/gdb/gdb_wchar.h b/gdb/gdb_wchar.h index fca3fe4..78f59a1 100644 --- a/gdb/gdb_wchar.h +++ b/gdb/gdb_wchar.h @@ -23,7 +23,11 @@ Capable systems have the full suite: wchar_t support and iconv (perhaps via GNU libiconv). On these machines, full functionality - is available. + is available. Note that full functionality is dependent on us + being able to convert from an arbitrary encoding to wchar_t. In + practice this means we look for __STDC_ISO_10646__ (where we know + the name of the wchar_t encoding) or GNU libiconv, where we can use + "wchar_t". DJGPP is known to have libiconv but not wchar_t support. On systems like this, we use the narrow character functions. The full @@ -35,8 +39,6 @@ wrappers for the wchar_t functionality we use. */ -#define INTERMEDIATE_ENCODING "wchar_t" - #if defined (HAVE_ICONV) #include <iconv.h> #else @@ -45,9 +47,15 @@ #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) +/* We use "btowc" as a sentinel to detect functioning wchar_t support. + We check for either __STDC_ISO_10646__ or a new-enough libiconv in + order to ensure we can convert to and from wchar_t. We choose + libiconv version 0x10D because it was reported that earlier + versions do not always accept "wchar_t" as an encoding argument on + Solaris. */ +#if defined (HAVE_ICONV) && defined (HAVE_WCHAR_H) && defined (HAVE_BTOWC) \ + && (defined (__STDC_ISO_10646__) \ + || defined (_LIBICONV_VERSION) && _LIBICONV_VERSION >= 0x10D) #include <wchar.h> #include <wctype.h> @@ -63,6 +71,25 @@ typedef wint_t gdb_wint_t; #define LCST(X) L ## X +/* If __STDC_ISO_10646__ is defined, then the host wchar_t is UCS-4. + We exploit this fact in the hope that there are hosts that define + this but which do not support "wchar_t" as an encoding argument to + iconv_open. We put the endianness into the encoding name to avoid + hosts that emit a BOM when the unadorned name is used. */ +#if defined (__STDC_ISO_10646__) +#if WORDS_BIGENDIAN +#define INTERMEDIATE_ENCODING "UCS-4BE" +#else +#define INTERMEDIATE_ENCODING "UCS-4LE" +#endif +#elif defined (_LIBICONV_VERSION) && _LIBICONV_VERSION >= 0x10D +#define INTERMEDIATE_ENCODING "wchar_t" +#else +/* This shouldn't happen, because the earlier #if should have filtered + out this case. */ +#error "Neither __STDC_ISO_10646__ nor _LIBICONV_VERSION defined" +#endif + #else typedef char gdb_wchar_t; @@ -80,8 +107,9 @@ typedef int gdb_wint_t; 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 +#ifdef PHONY_ICONV +#define INTERMEDIATE_ENCODING "wchar_t" +#else #define INTERMEDIATE_ENCODING host_charset () #endif ^ permalink raw reply [flat|nested] 40+ messages in thread
* RE: Your INTERMEDIATE_ENCODING patch for Solaris 2010-08-18 16:12 ` Tom Tromey @ 2010-08-19 15:03 ` Pierre Muller 2010-08-19 16:09 ` Tom Tromey 0 siblings, 1 reply; 40+ messages in thread From: Pierre Muller @ 2010-08-19 15:03 UTC (permalink / raw) To: 'Tom Tromey'; +Cc: gdb-patches Hi Tom, I think your patch still has a problem: if I have a system (like my i386 open solaris) that only has the libc iconv functions, but no libiconv) The libc headers do not set __STDC_ISO_10646__ nor defined _LIBICONV_VERSION macro. Thus we do not know how to handle those iconv functions. I think that we should simply ignore them by defining PHONY_ICONV in such cases. The problem is then that we already loaded libc iconv.h header which then leads to an error of conflicting types for iconv definition. This probably means that the check that in done inside gdb_wchar.h should be changed into a configuration macro, something like HAVE_USABLE_ICONV. Pierre PS: libc iconv on Solaris seems to work more or less, but it doesn't like 'ASCII' charset (don't know why..) but code in _initialize_charset does transform '646' into 'ASCII' which is bad. If LANG is set to en_US.UTF-8 for instance, the 'print version' works. So changing the '646' -> 'ASCII' into a '646' -> 'UTF-8' would also improve things for solaris, but I have no idea if this would also affect Non Solaris hosts. PS2: what about being able to disable iconv at configure level with --disable-iconv that would skip iconv checks and thus lead to PHONY_ICONV? ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Your INTERMEDIATE_ENCODING patch for Solaris 2010-08-19 15:03 ` Pierre Muller @ 2010-08-19 16:09 ` Tom Tromey 2010-08-30 18:01 ` Tom Tromey 0 siblings, 1 reply; 40+ messages in thread From: Tom Tromey @ 2010-08-19 16:09 UTC (permalink / raw) To: Pierre Muller; +Cc: gdb-patches >>>>> "Pierre" == Pierre Muller <pierre.muller@ics-cnrs.unistra.fr> writes: Pierre> Hi Tom, Pierre> I think your patch still has a problem: Pierre> if I have a system (like my i386 open solaris) Pierre> that only has the libc iconv functions, but no libiconv) Pierre> The libc headers do not set __STDC_ISO_10646__ Pierre> nor defined _LIBICONV_VERSION macro. Pierre> Thus we do not know how to handle those iconv functions. I don't really understand. Does this show up as a compile-time error? Or a runtime problem? Could you give more details? Pierre> I think that we should simply ignore them by defining Pierre> PHONY_ICONV in such cases. Yeah, we can do this. This reduces functionality a lot, and since Solaris does have a mostly working iconv it seems like we should try to use as much as we can. But, Solaris seems to make this as difficult as possible. Pierre> PS: libc iconv on Solaris seems to work more or less, Pierre> but it doesn't like 'ASCII' charset (don't know why..) Pierre> but code in _initialize_charset does transform '646' into 'ASCII' Pierre> which is bad. Oh, interesting. The reports I have heard are that, on Solaris, nl_langinfo(CODESET) returns "646", which is not a valid argument to iconv_open. I thought we knew that "ASCII" did work, but maybe it is version dependent or something. I think this is moot if we make the PHONY_ICONV change. Pierre> PS2: what about being able to disable iconv at configure level with Pierre> --disable-iconv Pierre> that would skip iconv checks and thus lead to Pierre> PHONY_ICONV? I'd prefer to avoid more configure options unless absolutely necessary. This area already has a lot of modes. Here's a new version that should disable iconv on this platform, among others. Tom b/gdb/ChangeLog: 2010-08-19 Tom Tromey <tromey@redhat.com> * charset.c (iconv_open): New define. (iconv): Likewise. (iconv_close): Likewise. (phony_iconv_open): Add "phony_" prefix. (phony_iconv_close): Likewise. (phony_iconv): Likewise. * gdb_wchar.h: Check _LIBICONV_VERSION, __STDC_ISO_10646__. Change how INTERMEDIATE_ENCODING is defined. diff --git a/gdb/charset.c b/gdb/charset.c index 43b7fa8..3274219 100644 --- a/gdb/charset.c +++ b/gdb/charset.c @@ -90,8 +90,11 @@ #undef iconv_t #define iconv_t int #undef iconv_open +#define iconv_open phony_iconv_open #undef iconv +#define iconv phony_iconv #undef iconv_close +#define iconv_close phony_iconv_close #undef ICONV_CONST #define ICONV_CONST const @@ -106,7 +109,7 @@ #endif iconv_t -iconv_open (const char *to, const char *from) +phony_iconv_open (const char *to, const char *from) { /* We allow conversions from UTF-32BE, wchar_t, and the host charset. We allow conversions to wchar_t and the host charset. */ @@ -122,14 +125,14 @@ iconv_open (const char *to, const char *from) } int -iconv_close (iconv_t arg) +phony_iconv_close (iconv_t arg) { return 0; } size_t -iconv (iconv_t utf_flag, const char **inbuf, size_t *inbytesleft, - char **outbuf, size_t *outbytesleft) +phony_iconv (iconv_t utf_flag, const char **inbuf, size_t *inbytesleft, + char **outbuf, size_t *outbytesleft) { if (utf_flag) { diff --git a/gdb/gdb_wchar.h b/gdb/gdb_wchar.h index fca3fe4..7b0f958 100644 --- a/gdb/gdb_wchar.h +++ b/gdb/gdb_wchar.h @@ -23,20 +23,24 @@ Capable systems have the full suite: wchar_t support and iconv (perhaps via GNU libiconv). On these machines, full functionality - is available. + is available. Note that full functionality is dependent on us + being able to convert from an arbitrary encoding to wchar_t. In + practice this means we look for __STDC_ISO_10646__ (where we know + the name of the wchar_t encoding) or GNU libiconv, where we can use + "wchar_t". 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. */ + Finally, some systems do not have iconv, or are really broken + (e.g., Solaris, which almost has all of this working, but where + just enough is broken to make it too hard to use). 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 @@ -45,9 +49,15 @@ #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) +/* We use "btowc" as a sentinel to detect functioning wchar_t support. + We check for either __STDC_ISO_10646__ or a new-enough libiconv in + order to ensure we can convert to and from wchar_t. We choose + libiconv version 0x10D because it was reported that earlier + versions do not always accept "wchar_t" as an encoding + argument. */ +#if defined (HAVE_ICONV) && defined (HAVE_WCHAR_H) && defined (HAVE_BTOWC) \ + && (defined (__STDC_ISO_10646__) \ + || (defined (_LIBICONV_VERSION) && _LIBICONV_VERSION >= 0x10D)) #include <wchar.h> #include <wctype.h> @@ -63,7 +73,32 @@ typedef wint_t gdb_wint_t; #define LCST(X) L ## X +/* If __STDC_ISO_10646__ is defined, then the host wchar_t is UCS-4. + We exploit this fact in the hope that there are hosts that define + this but which do not support "wchar_t" as an encoding argument to + iconv_open. We put the endianness into the encoding name to avoid + hosts that emit a BOM when the unadorned name is used. */ +#if defined (__STDC_ISO_10646__) +#if WORDS_BIGENDIAN +#define INTERMEDIATE_ENCODING "UCS-4BE" #else +#define INTERMEDIATE_ENCODING "UCS-4LE" +#endif +#elif defined (_LIBICONV_VERSION) && _LIBICONV_VERSION >= 0x10D +#define INTERMEDIATE_ENCODING "wchar_t" +#else +/* This shouldn't happen, because the earlier #if should have filtered + out this case. */ +#error "Neither __STDC_ISO_10646__ nor _LIBICONV_VERSION defined" +#endif + +#else + +/* If we got here and have wchar_t support, we might be on a system + with some problem. So, we just disable everything. */ +#if !(defined (HAVE_WCHAR_H) && defined (HAVE_BTOWC)) +#define PHONY_ICONV +#endif typedef char gdb_wchar_t; typedef int gdb_wint_t; @@ -80,8 +115,9 @@ typedef int gdb_wint_t; 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 +#ifdef PHONY_ICONV +#define INTERMEDIATE_ENCODING "wchar_t" +#else #define INTERMEDIATE_ENCODING host_charset () #endif ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Your INTERMEDIATE_ENCODING patch for Solaris 2010-08-19 16:09 ` Tom Tromey @ 2010-08-30 18:01 ` Tom Tromey 2010-08-31 9:25 ` Pierre Muller 0 siblings, 1 reply; 40+ messages in thread From: Tom Tromey @ 2010-08-30 18:01 UTC (permalink / raw) To: Pierre Muller; +Cc: gdb-patches >>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes: Tom> Here's a new version that should disable iconv on this platform, among Tom> others. Hi Pierre. Did this patch work for you? Tom ^ permalink raw reply [flat|nested] 40+ messages in thread
* RE: Your INTERMEDIATE_ENCODING patch for Solaris 2010-08-30 18:01 ` Tom Tromey @ 2010-08-31 9:25 ` Pierre Muller 2010-08-31 16:47 ` Tom Tromey 0 siblings, 1 reply; 40+ messages in thread From: Pierre Muller @ 2010-08-31 9:25 UTC (permalink / raw) To: 'Tom Tromey'; +Cc: gdb-patches > -----Message d'origine----- > De : gdb-patches-owner@sourceware.org [mailto:gdb-patches- > owner@sourceware.org] De la part de Tom Tromey > Envoyé : Monday, August 30, 2010 8:01 PM > À : Pierre Muller > Cc : gdb-patches@sourceware.org > Objet : Re: Your INTERMEDIATE_ENCODING patch for Solaris > > >>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes: > > Tom> Here's a new version that should disable iconv on this platform, > among > Tom> others. > > Hi Pierre. Did this patch work for you? Hi Tom, sorry for the delay: here are a few results: Test machine #1: uname -a output: SunOS opensolaris 5.11 snv_111b i86pc i386 i86pc Solaris With your patch, gdb compiles fine, gdbcvs/build-norm/gdb$ grep ICONV *.h config.h:#define HAVE_ICONV 1 config.h:/* #undef HAVE_ICONVLIST */ config.h:/* #undef HAVE_LIBICONVLIST */ config.h:#define ICONV_CONST const ./gdb ./gdb (top-gdb) p version $1 = "7.2.50.20100831-cvs" after replacing \r\n by \r+\n in charset.exp, I get: .../gdb/testsuite$ gmake check RUNTESTFLAGS=charset.exp === gdb Summary === # of expected passes 111 # of unexpected failures 50 (Do you want the detailed output?) (Without patch, but the same modified charset.exp, the printing of version fails I get: === gdb Summary === # of expected passes 74 # of unexpected failures 87 ) Test machine #2: uname -a output: uname -a SunOS muller 5.11 snv_111b sun4v sparc SUNW,Sun-Fire-T200 Solaris gdb/buildcvs/gdb$ ./gdb ./gdb (top-gdb) p version $1 = "7.2.50.20100831-cvs" (top-gdb) inf func iconv All functions matching regular expression "iconv": File ../../src/gdb/charset.c: size_t phony_iconv(int, const char **, size_t *, char **, size_t *); int phony_iconv_close(int); int phony_iconv_open(const char *, const char *); static void cleanup_iconv(void *); (top-gdb) q :/gdb/buildcvs/gdb$ grep ICONV *.h config.h:/* #undef HAVE_ICONV */ config.h:/* #undef HAVE_ICONVLIST */ config.h:/* #undef HAVE_LIBICONVLIST */ config.h:/* #undef ICONV_CONST */ So apparently on Sparc, the C library iconv is not found, despite the fact that it is in libc.so: /lib$ objdump -T libc.so |grep iconv 0005f768 g DF .text 00000034 SUNW_0.8 .protected iconv 0005f6e8 g DF .text 00000080 SUNW_0.8 .protected iconv_close 0005f000 g DF .text 000000b4 SUNW_0.8 .protected iconv_open After searching, it appears that the problem comes from the fact that /usr/local/include is searched before /usr/include, while /usr/local/lib is not searched at all for libraries. /usr/local/include/iconv.h contains the /usr/local/lib/libiconv.so header. Compilation without -liconv fails because /usr/local/include/iconv.h has: #define iconv libiconv but libiconv is not found in c library. and the second compilation with "-liconv" option fails because /usr/local/lib is not in the library search path. Ugly, no? For that machine, the output did not change as none of the ICONV macros are set. Test machine #3 x86_64 prcoessor: uname -a SunOS muller 5.11 snv_111b i86pc i386 i86pc Solaris gdb/build-64/gdb$ grep ICONV *.h config.h:#define HAVE_ICONV 1 config.h:/* #undef HAVE_ICONVLIST */ config.h:/* #undef HAVE_LIBICONVLIST */ config.h:#define ICONV_CONST const So this one uses c library iconv. (top-gdb) p version $1 = <error reading variable> (top-gdb) inf fun iconv All functions matching regular expression "iconv": File ../../src/gdb/charset.c: static void cleanup_iconv(void *); Non-debugging symbols: 0x0000000000514860 iconv_open 0x0000000000514860 iconv_open@plt 0x0000000000514870 iconv_close 0x0000000000514870 iconv_close@plt 0x0000000000514880 iconv 0x0000000000514880 iconv@plt (top-gdb) set host-charset UTF-8 (top-gdb) p version $2 = "7.2.50.20100831-cvs" So here, the c library iconv functions are used, but the default host-charset is set to ASCII which is not handled by that iconv :( So I would like to have the default host and target charset changed to UTF-8. It is of course possible to use: gdb/build-64/gdb$ export LANG=en_US.UTF-8 in that case, the defaults are set correctly: (top-gdb) p version $1 = "7.2.50.20100831-cvs" (top-gdb) show charset The host character set is "auto; currently UTF-8". The target character set is "auto; currently UTF-8". The target wide character set is "auto; currently UTF-32". But I would still prefer if we changed also the default to UTF-8 for solaris. Pierre ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Your INTERMEDIATE_ENCODING patch for Solaris 2010-08-31 9:25 ` Pierre Muller @ 2010-08-31 16:47 ` Tom Tromey 2010-09-01 7:30 ` Pierre Muller [not found] ` <44796.6229789474$1283326243@news.gmane.org> 0 siblings, 2 replies; 40+ messages in thread From: Tom Tromey @ 2010-08-31 16:47 UTC (permalink / raw) To: Pierre Muller; +Cc: gdb-patches >>>>> "Pierre" == Pierre Muller <pierre.muller@ics-cnrs.unistra.fr> writes: Pierre> After searching, it appears that the problem comes from the fact Pierre> that /usr/local/include is searched before /usr/include, Pierre> while /usr/local/lib is not searched at all for libraries. Yuck. This setup seems unfortunate but I don't think there is much gdb should do about it. Pierre> Test machine #3 x86_64 prcoessor: [...] Pierre> So this one uses c library iconv. Pierre> (top-gdb) p version Pierre> $1 = <error reading variable> Pierre> (top-gdb) inf fun iconv Pierre> All functions matching regular expression "iconv": Pierre> So here, the c library iconv functions are used, Pierre> but the default host-charset is set to ASCII which is Pierre> not handled by that iconv :( I am not sure how this happens with the patch I posted. Does this machine define __STDC_ISO_10646__? Or did I somehow get the #if logic wrong? Pierre> So I would like to have the default host and target Pierre> charset changed to UTF-8. What does nl_langinfo(CODESET) return on this sytem? If you remove the special "646" case, does it work? Tom ^ permalink raw reply [flat|nested] 40+ messages in thread
* RE: Your INTERMEDIATE_ENCODING patch for Solaris 2010-08-31 16:47 ` Tom Tromey @ 2010-09-01 7:30 ` Pierre Muller [not found] ` <44796.6229789474$1283326243@news.gmane.org> 1 sibling, 0 replies; 40+ messages in thread From: Pierre Muller @ 2010-09-01 7:30 UTC (permalink / raw) To: 'Tom Tromey'; +Cc: gdb-patches > -----Message d'origine----- > De : gdb-patches-owner@sourceware.org [mailto:gdb-patches- > owner@sourceware.org] De la part de Tom Tromey > Envoyé : Tuesday, August 31, 2010 6:47 PM > À : 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> After searching, it appears that the problem comes from the > fact > Pierre> that /usr/local/include is searched before /usr/include, > Pierre> while /usr/local/lib is not searched at all for libraries. > > Yuck. > > This setup seems unfortunate but I don't think there is much gdb should > do about it. I agree with you here :( > Pierre> Test machine #3 x86_64 prcoessor: > [...] > Pierre> So this one uses c library iconv. > Pierre> (top-gdb) p version > Pierre> $1 = <error reading variable> > Pierre> (top-gdb) inf fun iconv > Pierre> All functions matching regular expression "iconv": > > Pierre> So here, the c library iconv functions are used, > Pierre> but the default host-charset is set to ASCII which is > Pierre> not handled by that iconv :( > > I am not sure how this happens with the patch I posted. > Does this machine define __STDC_ISO_10646__? > Or did I somehow get the #if logic wrong? > Pierre> So I would like to have the default host and target > Pierre> charset changed to UTF-8. > > What does nl_langinfo(CODESET) return on this sytem? > If you remove the special "646" case, does it work? the ASCII charset is indeed set by the check to "646". If I replace this by (only the "646" specific change is listed): Index: charset.c =================================================================== RCS file: /cvs/src/src/gdb/charset.c,v retrieving revision 1.34 diff -u -p -r1.34 charset.c --- charset.c 24 Jun 2010 18:24:03 -0000 1.34 +++ charset.c 1 Sep 2010 07:28:23 -0000 @@ -928,7 +931,9 @@ _initialize_charset (void) /* Solaris will return `646' here -- but the Solaris iconv then does not accept this. Darwin (and maybe FreeBSD) may return "" here, which GNU libiconv doesn't like (infinite loop). */ - if (!strcmp (auto_host_charset_name, "646") || !*auto_host_charset_name) + if (!strcmp (auto_host_charset_name, "646")) + auto_host_charset_name = "UTF-8"; + else if (!*auto_host_charset_name) auto_host_charset_name = "ASCII"; auto_target_charset_name = auto_host_charset_name; #elif defined (USE_WIN32API) I do get a default of '"UTF-8" for Open Solaris machines, but I don't know if other systems might also return "646", but not like the "UTF-8" choice. In any case, having a LANG environment variable set to xx_XX.UTF-8 also allows to get a nicely working gdb. Pierre ^ permalink raw reply [flat|nested] 40+ messages in thread
[parent not found: <44796.6229789474$1283326243@news.gmane.org>]
* Re: Your INTERMEDIATE_ENCODING patch for Solaris [not found] ` <44796.6229789474$1283326243@news.gmane.org> @ 2010-09-01 22:35 ` Tom Tromey 2010-09-02 14:21 ` Pierre Muller 0 siblings, 1 reply; 40+ messages in thread From: Tom Tromey @ 2010-09-01 22:35 UTC (permalink / raw) To: Pierre Muller; +Cc: gdb-patches Pierre> So here, the c library iconv functions are used, Pierre> but the default host-charset is set to ASCII which is Pierre> not handled by that iconv :( Tom> I am not sure how this happens with the patch I posted. Tom> Does this machine define __STDC_ISO_10646__? Tom> Or did I somehow get the #if logic wrong? I didn't see an answer to this. I still don't understand how this particular build is using iconv and not the phony iconv. Pierre> I do get a default of '"UTF-8" for Open Solaris machines, Pierre> but I don't know if other systems might also return "646", Pierre> but not like the "UTF-8" choice. AFAIK only Solaris does this. It seems to me that UTF-8 is not correct, though -- it may vary by locale. Maybe we need to go even further and blacklist Solaris from ever using iconv :-(. It would help to know the answer to the above. Tom ^ permalink raw reply [flat|nested] 40+ messages in thread
* RE: Your INTERMEDIATE_ENCODING patch for Solaris 2010-09-01 22:35 ` Tom Tromey @ 2010-09-02 14:21 ` Pierre Muller 2010-09-02 15:39 ` Tom Tromey 0 siblings, 1 reply; 40+ messages in thread From: Pierre Muller @ 2010-09-02 14:21 UTC (permalink / raw) To: 'Tom Tromey'; +Cc: gdb-patches > -----Message d'origine----- > De : gdb-patches-owner@sourceware.org [mailto:gdb-patches- > owner@sourceware.org] De la part de Tom Tromey > Envoyé : Thursday, September 02, 2010 12:22 AM > À : Pierre Muller > Cc : gdb-patches@sourceware.org > Objet : Re: Your INTERMEDIATE_ENCODING patch for Solaris > > Pierre> So here, the c library iconv functions are used, > Pierre> but the default host-charset is set to ASCII which is > Pierre> not handled by that iconv :( > > Tom> I am not sure how this happens with the patch I posted. > Tom> Does this machine define __STDC_ISO_10646__? > Tom> Or did I somehow get the #if logic wrong? > > I didn't see an answer to this. > I still don't understand how this particular build is using iconv and > not the phony iconv. Sorry, after investigation it appears that: __STDC_ISO_10646__ is not in any headers under /usr/include but both HAVE_WCHAR_T and HAVE_BTOWC are defined, so that with you patch PHONY_ICONV macro doesn't get set. Does this answer your question? > Pierre> I do get a default of '"UTF-8" for Open Solaris machines, > Pierre> but I don't know if other systems might also return "646", > Pierre> but not like the "UTF-8" choice. > > AFAIK only Solaris does this. It seems to me that UTF-8 is not > correct, > though -- it may vary by locale. > > Maybe we need to go even further and blacklist Solaris from ever using > iconv :-(. It would help to know the answer to the above. Probably just define PHONY_ICONV if the first set of conditions is not met (by the way, I am not sure the libiconv version test that we added is really pertinent.) Pierre ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Your INTERMEDIATE_ENCODING patch for Solaris 2010-09-02 14:21 ` Pierre Muller @ 2010-09-02 15:39 ` Tom Tromey 2010-09-14 21:29 ` Tom Tromey 0 siblings, 1 reply; 40+ messages in thread From: Tom Tromey @ 2010-09-02 15:39 UTC (permalink / raw) To: Pierre Muller; +Cc: gdb-patches Pierre> Probably just define PHONY_ICONV if the first set of conditions is Pierre> not met (by the way, I am not sure the libiconv version test Pierre> that we added is really pertinent.) Thanks. I think I got the logic wrong: +/* If we got here and have wchar_t support, we might be on a system + with some problem. So, we just disable everything. */ +#if !(defined (HAVE_WCHAR_H) && defined (HAVE_BTOWC)) +#define PHONY_ICONV +#endif I think that "!" is wrong -- it even contradicts the comment. I'm sorry to keep bothering you about this, but could you remove that "!" and try again? Tom ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Your INTERMEDIATE_ENCODING patch for Solaris 2010-09-02 15:39 ` Tom Tromey @ 2010-09-14 21:29 ` Tom Tromey 2010-09-15 17:20 ` Pierre Muller 0 siblings, 1 reply; 40+ messages in thread From: Tom Tromey @ 2010-09-14 21:29 UTC (permalink / raw) To: Pierre Muller; +Cc: gdb-patches >>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes: Pierre> Probably just define PHONY_ICONV if the first set of conditions is Pierre> not met (by the way, I am not sure the libiconv version test Pierre> that we added is really pertinent.) Tom> Thanks. I think I got the logic wrong: Tom> +/* If we got here and have wchar_t support, we might be on a system Tom> + with some problem. So, we just disable everything. */ Tom> +#if !(defined (HAVE_WCHAR_H) && defined (HAVE_BTOWC)) Tom> +#define PHONY_ICONV Tom> +#endif Tom> I think that "!" is wrong -- it even contradicts the comment. Tom> I'm sorry to keep bothering you about this, but could you remove that Tom> "!" and try again? Any word on this? I would like to commit this patch if it seems ok. Tom ^ permalink raw reply [flat|nested] 40+ messages in thread
* RE: Your INTERMEDIATE_ENCODING patch for Solaris 2010-09-14 21:29 ` Tom Tromey @ 2010-09-15 17:20 ` Pierre Muller 2010-09-16 7:55 ` Tom Tromey 0 siblings, 1 reply; 40+ messages in thread From: Pierre Muller @ 2010-09-15 17:20 UTC (permalink / raw) To: 'Tom Tromey'; +Cc: gdb-patches > -----Message d'origine----- > De : gdb-patches-owner@sourceware.org [mailto:gdb-patches- > owner@sourceware.org] De la part de Tom Tromey > Envoyé : Tuesday, September 14, 2010 10:57 PM > À : Pierre Muller > Cc : gdb-patches@sourceware.org > Objet : Re: Your INTERMEDIATE_ENCODING patch for Solaris > > >>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes: > > Pierre> Probably just define PHONY_ICONV if the first set of conditions > is > Pierre> not met (by the way, I am not sure the libiconv version test > Pierre> that we added is really pertinent.) > > Tom> Thanks. I think I got the logic wrong: > > Tom> +/* If we got here and have wchar_t support, we might be on a > system > Tom> + with some problem. So, we just disable everything. */ > Tom> +#if !(defined (HAVE_WCHAR_H) && defined (HAVE_BTOWC)) > Tom> +#define PHONY_ICONV > Tom> +#endif > > Tom> I think that "!" is wrong -- it even contradicts the comment. > Tom> I'm sorry to keep bothering you about this, but could you remove > that > Tom> "!" and try again? > > Any word on this? > I would like to commit this patch if it seems ok. I can at least confirm that for Sparc OpenSolaris 5.11 snv_111b it does disable use of iconv functions from libc.so.1 So, at least for me, this should be modified that way. Pierre ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Your INTERMEDIATE_ENCODING patch for Solaris 2010-09-15 17:20 ` Pierre Muller @ 2010-09-16 7:55 ` Tom Tromey 2010-09-16 9:49 ` Pierre Muller 2010-09-16 17:51 ` [patch] Regression on py-prettyprint.exp: print estring [Re: Your INTERMEDIATE_ENCODING patch for Solaris] Jan Kratochvil 0 siblings, 2 replies; 40+ messages in thread From: Tom Tromey @ 2010-09-16 7:55 UTC (permalink / raw) To: Pierre Muller; +Cc: gdb-patches >>>>> "Pierre" == Pierre Muller <pierre.muller@ics-cnrs.unistra.fr> writes: Pierre> I can at least confirm that for Pierre> Sparc OpenSolaris 5.11 snv_111b it does Pierre> disable use of iconv functions from libc.so.1 Pierre> So, at least for me, this should be modified Pierre> that way. Great. Here is what I am checking in. Tom 2010-09-15 Tom Tromey <tromey@redhat.com> * charset.c (iconv_open): New define. (iconv): Likewise. (iconv_close): Likewise. (phony_iconv_open): Add "phony_" prefix. (phony_iconv_close): Likewise. (phony_iconv): Likewise. * gdb_wchar.h: Check _LIBICONV_VERSION, __STDC_ISO_10646__. Change how INTERMEDIATE_ENCODING is defined. Index: charset.c =================================================================== RCS file: /cvs/src/src/gdb/charset.c,v retrieving revision 1.34 diff -u -r1.34 charset.c --- charset.c 24 Jun 2010 18:24:03 -0000 1.34 +++ charset.c 15 Sep 2010 20:03:02 -0000 @@ -90,8 +90,11 @@ #undef iconv_t #define iconv_t int #undef iconv_open +#define iconv_open phony_iconv_open #undef iconv +#define iconv phony_iconv #undef iconv_close +#define iconv_close phony_iconv_close #undef ICONV_CONST #define ICONV_CONST const @@ -106,7 +109,7 @@ #endif iconv_t -iconv_open (const char *to, const char *from) +phony_iconv_open (const char *to, const char *from) { /* We allow conversions from UTF-32BE, wchar_t, and the host charset. We allow conversions to wchar_t and the host charset. */ @@ -122,14 +125,14 @@ } int -iconv_close (iconv_t arg) +phony_iconv_close (iconv_t arg) { return 0; } size_t -iconv (iconv_t utf_flag, const char **inbuf, size_t *inbytesleft, - char **outbuf, size_t *outbytesleft) +phony_iconv (iconv_t utf_flag, const char **inbuf, size_t *inbytesleft, + char **outbuf, size_t *outbytesleft) { if (utf_flag) { Index: gdb_wchar.h =================================================================== RCS file: /cvs/src/src/gdb/gdb_wchar.h,v retrieving revision 1.3 diff -u -r1.3 gdb_wchar.h --- gdb_wchar.h 1 Jan 2010 07:31:32 -0000 1.3 +++ gdb_wchar.h 15 Sep 2010 20:03:02 -0000 @@ -23,20 +23,24 @@ Capable systems have the full suite: wchar_t support and iconv (perhaps via GNU libiconv). On these machines, full functionality - is available. + is available. Note that full functionality is dependent on us + being able to convert from an arbitrary encoding to wchar_t. In + practice this means we look for __STDC_ISO_10646__ (where we know + the name of the wchar_t encoding) or GNU libiconv, where we can use + "wchar_t". 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. */ + Finally, some systems do not have iconv, or are really broken + (e.g., Solaris, which almost has all of this working, but where + just enough is broken to make it too hard to use). 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 @@ -45,9 +49,15 @@ #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) +/* We use "btowc" as a sentinel to detect functioning wchar_t support. + We check for either __STDC_ISO_10646__ or a new-enough libiconv in + order to ensure we can convert to and from wchar_t. We choose + libiconv version 0x10D because it was reported that earlier + versions do not always accept "wchar_t" as an encoding + argument. */ +#if defined (HAVE_ICONV) && defined (HAVE_WCHAR_H) && defined (HAVE_BTOWC) \ + && (defined (__STDC_ISO_10646__) \ + || (defined (_LIBICONV_VERSION) && _LIBICONV_VERSION >= 0x10D)) #include <wchar.h> #include <wctype.h> @@ -63,7 +73,32 @@ #define LCST(X) L ## X +/* If __STDC_ISO_10646__ is defined, then the host wchar_t is UCS-4. + We exploit this fact in the hope that there are hosts that define + this but which do not support "wchar_t" as an encoding argument to + iconv_open. We put the endianness into the encoding name to avoid + hosts that emit a BOM when the unadorned name is used. */ +#if defined (__STDC_ISO_10646__) +#if WORDS_BIGENDIAN +#define INTERMEDIATE_ENCODING "UCS-4BE" #else +#define INTERMEDIATE_ENCODING "UCS-4LE" +#endif +#elif defined (_LIBICONV_VERSION) && _LIBICONV_VERSION >= 0x10D +#define INTERMEDIATE_ENCODING "wchar_t" +#else +/* This shouldn't happen, because the earlier #if should have filtered + out this case. */ +#error "Neither __STDC_ISO_10646__ nor _LIBICONV_VERSION defined" +#endif + +#else + +/* If we got here and have wchar_t support, we might be on a system + with some problem. So, we just disable everything. */ +#if defined (HAVE_WCHAR_H) && defined (HAVE_BTOWC) +#define PHONY_ICONV +#endif typedef char gdb_wchar_t; typedef int gdb_wint_t; @@ -80,8 +115,9 @@ 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 +#ifdef PHONY_ICONV +#define INTERMEDIATE_ENCODING "wchar_t" +#else #define INTERMEDIATE_ENCODING host_charset () #endif ^ permalink raw reply [flat|nested] 40+ messages in thread
* RE: Your INTERMEDIATE_ENCODING patch for Solaris 2010-09-16 7:55 ` Tom Tromey @ 2010-09-16 9:49 ` Pierre Muller 2010-09-16 20:22 ` Tom Tromey 2010-09-16 17:51 ` [patch] Regression on py-prettyprint.exp: print estring [Re: Your INTERMEDIATE_ENCODING patch for Solaris] Jan Kratochvil 1 sibling, 1 reply; 40+ messages in thread From: Pierre Muller @ 2010-09-16 9:49 UTC (permalink / raw) To: 'Tom Tromey'; +Cc: gdb-patches > -----Message d'origine----- > De : gdb-patches-owner@sourceware.org [mailto:gdb-patches- > owner@sourceware.org] De la part de Tom Tromey > Envoyé : Wednesday, September 15, 2010 10:18 PM > À : 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> I can at least confirm that for > Pierre> Sparc OpenSolaris 5.11 snv_111b it does > Pierre> disable use of iconv functions from libc.so.1 > > Pierre> So, at least for me, this should be modified > Pierre> that way. > > Great. Here is what I am checking in. Nice, but I was wondering if the check of libiconv version is still needed. Wasn't it suggested by me? I think that checking for the existence of _LIBICONV_VERSION macro should be enough, unless you are really sure that older versions do not work. On systems that have an older GNU libiconv version installed, this might disable the use of GNU libiconv without a good reason. Pierre ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Your INTERMEDIATE_ENCODING patch for Solaris 2010-09-16 9:49 ` Pierre Muller @ 2010-09-16 20:22 ` Tom Tromey 2010-09-16 22:31 ` Pierre Muller [not found] ` <20078.2261243605$1284672670@news.gmane.org> 0 siblings, 2 replies; 40+ messages in thread From: Tom Tromey @ 2010-09-16 20:22 UTC (permalink / raw) To: Pierre Muller; +Cc: gdb-patches >>>>> "Pierre" == Pierre Muller <pierre.muller@ics-cnrs.unistra.fr> writes: Tom> Great. Here is what I am checking in. Pierre> Nice, but I was wondering if the Pierre> check of libiconv version is still needed. Pierre> Wasn't it suggested by me? According to the comment, versions of libiconv before 0x10D do not support "wchar_t" as an argument to iconv_open. I think you discovered this, but it is hard to remember. Pierre> I think that checking for the existence of Pierre> _LIBICONV_VERSION macro should be enough, Pierre> unless you are really sure that older versions Pierre> do not work. Pierre> On systems that have an older GNU libiconv Pierre> version installed, this might disable the use of GNU libiconv Pierre> without a good reason. I think it is better to fail safe: If this code is disabled, the user gets reduced functionality. If this code is erroneously enabled, users can't print strings at all. Tom ^ permalink raw reply [flat|nested] 40+ messages in thread
* RE: Your INTERMEDIATE_ENCODING patch for Solaris 2010-09-16 20:22 ` Tom Tromey @ 2010-09-16 22:31 ` Pierre Muller [not found] ` <20078.2261243605$1284672670@news.gmane.org> 1 sibling, 0 replies; 40+ messages in thread From: Pierre Muller @ 2010-09-16 22:31 UTC (permalink / raw) To: 'Tom Tromey'; +Cc: gdb-patches > -----Message d'origine----- > De : gdb-patches-owner@sourceware.org [mailto:gdb-patches- > owner@sourceware.org] De la part de Tom Tromey > Envoyé : Thursday, September 16, 2010 8:31 PM > À : 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: > > Tom> Great. Here is what I am checking in. > > Pierre> Nice, but I was wondering if the > Pierre> check of libiconv version is still needed. > Pierre> Wasn't it suggested by me? > > According to the comment, versions of libiconv before 0x10D do not > support "wchar_t" as an argument to iconv_open. > > I think you discovered this, but it is hard to remember. Yes, I wrote that in http://sourceware.org/ml/gdb-patches/2010-08/msg00296.html but I now fear that I made an error in my analysis at that time. Rereading my email lets me think that maybe the Sparc did not link to GNU iconv library, but instead tried to use the libc iconv functions. Troubles is that I lost access to that Sparc machine. > Pierre> I think that checking for the existence of > Pierre> _LIBICONV_VERSION macro should be enough, > Pierre> unless you are really sure that older versions > Pierre> do not work. > Pierre> On systems that have an older GNU libiconv > Pierre> version installed, this might disable the use of GNU libiconv > Pierre> without a good reason. > > I think it is better to fail safe: > If this code is disabled, the user gets reduced functionality. > If this code is erroneously enabled, users can't print strings at all. Would it be possible to test an old libiconv on some other platform? Pierre ^ permalink raw reply [flat|nested] 40+ messages in thread
[parent not found: <20078.2261243605$1284672670@news.gmane.org>]
* Re: Your INTERMEDIATE_ENCODING patch for Solaris [not found] ` <20078.2261243605$1284672670@news.gmane.org> @ 2010-09-17 9:21 ` Tom Tromey 2010-09-17 13:48 ` Pierre Muller 0 siblings, 1 reply; 40+ messages in thread From: Tom Tromey @ 2010-09-17 9:21 UTC (permalink / raw) To: Pierre Muller; +Cc: gdb-patches >>>>> "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. Tom ^ permalink raw reply [flat|nested] 40+ messages in thread
* RE: Your INTERMEDIATE_ENCODING patch for Solaris 2010-09-17 9:21 ` Tom Tromey @ 2010-09-17 13:48 ` Pierre Muller 2010-09-23 13:00 ` Tom Tromey 0 siblings, 1 reply; 40+ messages in thread From: Pierre Muller @ 2010-09-17 13:48 UTC (permalink / raw) To: 'Tom Tromey'; +Cc: gdb-patches > -----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... ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Your INTERMEDIATE_ENCODING patch for Solaris 2010-09-17 13:48 ` Pierre Muller @ 2010-09-23 13:00 ` Tom Tromey 2010-09-23 14:48 ` Pierre Muller 0 siblings, 1 reply; 40+ messages in thread From: Tom Tromey @ 2010-09-23 13:00 UTC (permalink / raw) To: Pierre Muller; +Cc: gdb-patches >>>>> "Pierre" == Pierre Muller <pierre.muller@ics-cnrs.unistra.fr> writes: Pierre> I found the libiconv version 1.5 Pierre> installed it on a x86 Open Solaris machine, Pierre> modified gdb_wchar.h to use _LIBICONV_VERSION >= 0x105 Pierre> and got an gdb executable linked to libiconv version 1.5, Pierre> using --with-libiconv-prefix=/usr/local/src/test32 Pierre> (the installation prefix I used for 1.5 libiconv). Pierre> I tested charset.exp result on that executable, Pierre> and got a lot of failures: [...] Pierre> But I was wondering if the problem is not coming from the Pierre> fact that for 1.5 libiconv find_charset_names function Pierre> directly calls 'iconv -l' (because iconvlist is not present Pierre> in this version of the library). Ouch. Pierre> I also downloaded version 1.8 of libiconv, Pierre> and checked GDB linked to that version: Pierre> the results of charset.exp are the same as 1.13.1 (2 FAILs) Yeah, how about we make x0108 the minimal acceptable version? It was released in 2002, that seems plenty old to me. If you agree, I will make the change. Pierre> PS: Support of libc iconv for Solaris could probably be Pierre> enhanced by a better parsing of 'iconv -l' output... I think there isn't much reason to do it, since we're planning to avoid Solaris iconv completely. If somebody wants to make the effort, though, it is fine by me. Tom ^ permalink raw reply [flat|nested] 40+ messages in thread
* RE: Your INTERMEDIATE_ENCODING patch for Solaris 2010-09-23 13:00 ` Tom Tromey @ 2010-09-23 14:48 ` Pierre Muller 2010-09-27 18:42 ` Tom Tromey 0 siblings, 1 reply; 40+ messages in thread From: Pierre Muller @ 2010-09-23 14:48 UTC (permalink / raw) To: 'Tom Tromey'; +Cc: gdb-patches > -----Message d'origine----- > De : gdb-patches-owner@sourceware.org [mailto:gdb-patches- > owner@sourceware.org] De la part de Tom Tromey > Envoyé : Wednesday, September 22, 2010 10:57 PM > À : 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> I found the libiconv version 1.5 > Pierre> installed it on a x86 Open Solaris machine, > Pierre> modified gdb_wchar.h to use _LIBICONV_VERSION >= 0x105 > Pierre> and got an gdb executable linked to libiconv version 1.5, > Pierre> using --with-libiconv-prefix=/usr/local/src/test32 > Pierre> (the installation prefix I used for 1.5 libiconv). > Pierre> I tested charset.exp result on that executable, > Pierre> and got a lot of failures: > [...] > > Pierre> But I was wondering if the problem is not coming from the > Pierre> fact that for 1.5 libiconv find_charset_names function > Pierre> directly calls 'iconv -l' (because iconvlist is not present > Pierre> in this version of the library). > > Ouch. > > Pierre> I also downloaded version 1.8 of libiconv, > Pierre> and checked GDB linked to that version: > Pierre> the results of charset.exp are the same as 1.13.1 (2 FAILs) > > Yeah, how about we make x0108 the minimal acceptable version? > It was released in 2002, that seems plenty old to me. > > If you agree, I will make the change. I agree, furthermore HAVE_LIBICONVLIST should always be set in config.h in that case, which avoids the direct call to 'iconv -l'. > Pierre> PS: Support of libc iconv for Solaris could probably be > Pierre> enhanced by a better parsing of 'iconv -l' output... > > I think there isn't much reason to do it, since we're planning to avoid > Solaris iconv completely. If somebody wants to make the effort, > though, > it is fine by me. Not sure I will have time for that... Pierre ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Your INTERMEDIATE_ENCODING patch for Solaris 2010-09-23 14:48 ` Pierre Muller @ 2010-09-27 18:42 ` Tom Tromey 0 siblings, 0 replies; 40+ messages in thread From: Tom Tromey @ 2010-09-27 18:42 UTC (permalink / raw) To: Pierre Muller; +Cc: gdb-patches Tom> Yeah, how about we make x0108 the minimal acceptable version? Tom> It was released in 2002, that seems plenty old to me. Tom> If you agree, I will make the change. Pierre> I agree, furthermore HAVE_LIBICONVLIST Pierre> should always be set in config.h in that case, Pierre> which avoids the direct call to 'iconv -l'. Here is the patch I am checking in. Thank you for all the testing you did for this. Tom 2010-09-27 Tom Tromey <tromey@redhat.com> * gdb_wchar.h: Change minimum libiconv to 0x108. Index: gdb_wchar.h =================================================================== RCS file: /cvs/src/src/gdb/gdb_wchar.h,v retrieving revision 1.4 diff -u -r1.4 gdb_wchar.h --- gdb_wchar.h 15 Sep 2010 20:18:47 -0000 1.4 +++ gdb_wchar.h 27 Sep 2010 17:21:10 -0000 @@ -52,12 +52,11 @@ /* We use "btowc" as a sentinel to detect functioning wchar_t support. We check for either __STDC_ISO_10646__ or a new-enough libiconv in order to ensure we can convert to and from wchar_t. We choose - libiconv version 0x10D because it was reported that earlier - versions do not always accept "wchar_t" as an encoding - argument. */ + libiconv version 0x108 because it is the first version with + iconvlist. */ #if defined (HAVE_ICONV) && defined (HAVE_WCHAR_H) && defined (HAVE_BTOWC) \ && (defined (__STDC_ISO_10646__) \ - || (defined (_LIBICONV_VERSION) && _LIBICONV_VERSION >= 0x10D)) + || (defined (_LIBICONV_VERSION) && _LIBICONV_VERSION >= 0x108)) #include <wchar.h> #include <wctype.h> @@ -84,7 +83,7 @@ #else #define INTERMEDIATE_ENCODING "UCS-4LE" #endif -#elif defined (_LIBICONV_VERSION) && _LIBICONV_VERSION >= 0x10D +#elif defined (_LIBICONV_VERSION) && _LIBICONV_VERSION >= 0x108 #define INTERMEDIATE_ENCODING "wchar_t" #else /* This shouldn't happen, because the earlier #if should have filtered ^ permalink raw reply [flat|nested] 40+ messages in thread
* [patch] Regression on py-prettyprint.exp: print estring [Re: Your INTERMEDIATE_ENCODING patch for Solaris] 2010-09-16 7:55 ` Tom Tromey 2010-09-16 9:49 ` Pierre Muller @ 2010-09-16 17:51 ` Jan Kratochvil 2010-09-16 20:33 ` Tom Tromey 1 sibling, 1 reply; 40+ messages in thread From: Jan Kratochvil @ 2010-09-16 17:51 UTC (permalink / raw) To: Tom Tromey; +Cc: Pierre Muller, gdb-patches On Wed, 15 Sep 2010 22:18:07 +0200, Tom Tromey wrote: > Great. Here is what I am checking in. > > 2010-09-15 Tom Tromey <tromey@redhat.com> > > * charset.c (iconv_open): New define. > (iconv): Likewise. > (iconv_close): Likewise. > (phony_iconv_open): Add "phony_" prefix. > (phony_iconv_close): Likewise. > (phony_iconv): Likewise. > * gdb_wchar.h: Check _LIBICONV_VERSION, __STDC_ISO_10646__. > Change how INTERMEDIATE_ENCODING is defined. 562fabbaa40fe9e601eddc2e0ab3c8cc615cf9a3 This patch has a regression on all the tested OSes {x86_64,x86_64-m32,i686}-fedora{12,13,14snapshot}-linux-gnu: (gdb) print estring $7 = "embedded x\201\202\203\204" PASS: gdb.python/py-prettyprint.exp: print estring -> (gdb) print estring $7 = "embedded \201\202\203\204" (gdb) FAIL: gdb.python/py-prettyprint.exp: print estring due to the change: INTERMEDIATE_ENCODING = "wchar_t" -> INTERMEDIATE_ENCODING = "UCS-4LE" echo 'char s[]="ab\201";'|gcc -o 1.o -c -g -x c -;./gdb -nx -q -ex 'p s' -ex q ./1.o $1 = "ab\201" -> $1 = "a\201" The fix has no regressions on {x86_64,x86_64-m32,i686}-fedora14snapshot-linux-gnu. Test OpenSolaris 2009.06 snv_111b X86 shows no problem even with FSF GDB HEAD; there was no libiconv so charset.exp is UNTESTED. (I did not try GNU libiconv on OpenSolaris). The fix seems generally correct to me anyway. The conversion may not stop when it seens no more output space as the input may no longer produce any output. It is more questionable why wchar_t worked (and how is it different in glibc iconv). Thanks, Jan gdb/ 2010-09-16 Jan Kratochvil <jan.kratochvil@redhat.com> * charset.c (wchar_iterate) <EILSEQ>: Return any possibly converted characters. --- a/gdb/charset.c +++ b/gdb/charset.c @@ -648,8 +648,13 @@ wchar_iterate (struct wchar_iterator *iter, switch (errno) { case EILSEQ: - /* Invalid input sequence. Skip it, and let the caller - know about it. */ + /* Invalid input sequence. We still might have converted a + character; if so, return it. */ + if (out_avail < out_request * sizeof (gdb_wchar_t)) + break; + + /* Otherwise skip the first invalid character, and let the + caller know about it. */ *out_result = wchar_iterate_invalid; *ptr = iter->input; *len = iter->width; ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [patch] Regression on py-prettyprint.exp: print estring [Re: Your INTERMEDIATE_ENCODING patch for Solaris] 2010-09-16 17:51 ` [patch] Regression on py-prettyprint.exp: print estring [Re: Your INTERMEDIATE_ENCODING patch for Solaris] Jan Kratochvil @ 2010-09-16 20:33 ` Tom Tromey 2010-09-16 20:44 ` Jan Kratochvil 0 siblings, 1 reply; 40+ messages in thread From: Tom Tromey @ 2010-09-16 20:33 UTC (permalink / raw) To: Jan Kratochvil; +Cc: Pierre Muller, gdb-patches >>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes: Jan> The fix seems generally correct to me anyway. The conversion may Jan> not stop when it seens no more output space as the input may no Jan> longer produce any output. It is more questionable why wchar_t Jan> worked (and how is it different in glibc iconv). Jan> 2010-09-16 Jan Kratochvil <jan.kratochvil@redhat.com> Jan> * charset.c (wchar_iterate) <EILSEQ>: Return any possibly converted Jan> characters. Thanks, I agree this is correct. Tom ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [patch] Regression on py-prettyprint.exp: print estring [Re: Your INTERMEDIATE_ENCODING patch for Solaris] 2010-09-16 20:33 ` Tom Tromey @ 2010-09-16 20:44 ` Jan Kratochvil 0 siblings, 0 replies; 40+ messages in thread From: Jan Kratochvil @ 2010-09-16 20:44 UTC (permalink / raw) To: Tom Tromey; +Cc: Pierre Muller, gdb-patches On Thu, 16 Sep 2010 21:17:02 +0200, Tom Tromey wrote: > Jan> 2010-09-16 Jan Kratochvil <jan.kratochvil@redhat.com> > Jan> * charset.c (wchar_iterate) <EILSEQ>: Return any possibly converted > Jan> characters. > > Thanks, I agree this is correct. Checked-in: http://sourceware.org/ml/gdb-cvs/2010-09/msg00116.html Thanks, Jan ^ permalink raw reply [flat|nested] 40+ messages in thread
* RE: Your INTERMEDIATE_ENCODING patch for Solaris 2010-08-17 19:03 ` Tom Tromey 2010-08-18 10:14 ` Joel Brobecker @ 2010-08-18 11:52 ` Pierre Muller 1 sibling, 0 replies; 40+ messages in thread From: Pierre Muller @ 2010-08-18 11:52 UTC (permalink / raw) To: 'Tom Tromey'; +Cc: gdb-patches I can confirm that on a 32-bit i386 OpenSolaris 2.11, the current CVS tree has the ICONV problem, which is solved by this patch. Thus I fully support your patch, with a small modification required for PHONY_ICONV, see below. The easiest way to see the difference is (gdbcvs is the executable generated by current CVS HEAD, gdb is the patched executable). With: ./gdbcvs ./gdb ..... (top-gdb) p version $1 = <error reading variable> While with: ./gdb ./gdb ..... (top-gdb) p version $1 = "7.2.50.20100818-cvs" I do have other problems with the x86_64 and sparc OpenSolaris versions I tried to compile, but those are not directly related to the ICONV issue (at least not only!). For the x86_64, I had two linking problems: 1) gcc claims that it doesn't know -rdynamic option gcc --version returns this: gcc (GCC) 3.4.3 (csl-sol210-3_4-20050802) "gcc --print-prog-name=ld" returned "/usr/ccs/bin/ld" and "`gcc --print-prog-name=ld` --version" returned: ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.1689 The compilation was done using the 5 lines long script: #!/usr/bin/env bash mkdir build64 cd build64 ../src/configure --build=x86_64-pc-solaris2.11 --disable-gdbtk CFLAGS="-g -O0 -m64" make all-gdb 2) gdb_curses.h was loading ncurses/ncurses.h header, but the library was /lib/64/libcurses.so.1, not a ncurses library. This led to unresolved symbols waddr_on/waddr_off (coming from macro definitions waddron and waddroff inside "ncurses/ncurses.h" header). (I finally found the origin of that problem: I installed libiconv from BlastWave into /opt/csw directory, but this directory was not searched for libraries..). Manually disabling the #define HAVE_NCURSES_NCURSES_H 1 line in config.h allowed to complete the compilation successfully. I don't know if this is just an installation problem on my side or a more general issue. Here the generated debugger did not show the ICONV problem, as no iconv function was found. After application of your patch however, I get this: gcc -g -O0 -m64 -I. -I../../src/gdb -I../../src/gdb/common -I../../src/gdb/con fig -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H -I../../src/gdb/.. /include/opcode -I../../src/gdb/../opcodes/.. -I../../src/gdb/../readline/.. -I. ./bfd -I../../src/gdb/../bfd -I../../src/gdb/../include -I../libdecnumber -I../. ./src/gdb/../libdecnumber -I../../src/gdb/gnulib -Ignulib -DMI_OUT=1 -DTUI=1 -I/usr/include -I/usr/include -Wall -Wdeclaration-after-statement -Wpointer-ari th -Wformat-nonliteral -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Werror -c -o charset.o -MT charset.o -MMD -MP -MF .deps/ch arset.Tpo ../../src/gdb/charset.c ../../src/gdb/charset.c: In function `make_wchar_iterator': ../../src/gdb/charset.c:585: error: `INTERMEDIATE_ENCODING' undeclared (first us e in this function) ../../src/gdb/charset.c:585: error: (Each undeclared identifier is reported only once ../../src/gdb/charset.c:585: error: for each function it appears in.) make: *** [charset.o] Error 1 This is because there is an error in your patch: if PHONY_ICONV is defined, INTERMEDIATE_ENCODING is not set at all anymore. Removing the #ifndef PHONY_ICONV around INTERMEDIATE_ENCODING definition in the bottom of gdb_wchar.h file fixes that issue. I still needed to disable HAVE_NUCURSES_NCURSES_H to be able to compile GDB. I will try to use CSW libiconv to see what happens then. Pierre Muller Pascal language support maintainer for GDB ^ permalink raw reply [flat|nested] 40+ messages in thread
end of thread, other threads:[~2010-09-27 17:28 UTC | newest] Thread overview: 40+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-07-31 16:25 Your INTERMEDIATE_ENCODING patch for Solaris Kazu Hirata 2010-08-05 18:40 ` Tom Tromey 2010-08-10 20:28 ` Daniel Jacobowitz 2010-08-17 18:06 ` Tom Tromey 2010-08-17 18:44 ` Joel Brobecker 2010-08-17 19:03 ` Tom Tromey 2010-08-18 10:14 ` Joel Brobecker 2010-08-18 14:43 ` Pierre Muller 2010-08-18 14:52 ` Joel Brobecker 2010-08-18 15:10 ` Pierre Muller 2010-08-18 15:35 ` Tom Tromey 2010-08-18 15:44 ` Tom Tromey 2010-08-18 16:36 ` Joel Brobecker 2010-08-18 17:35 ` Tom Tromey 2010-08-18 17:41 ` Joel Brobecker [not found] ` <15264.6257346079$1282142643@news.gmane.org> 2010-08-18 16:12 ` Tom Tromey 2010-08-19 15:03 ` Pierre Muller 2010-08-19 16:09 ` Tom Tromey 2010-08-30 18:01 ` Tom Tromey 2010-08-31 9:25 ` Pierre Muller 2010-08-31 16:47 ` Tom Tromey 2010-09-01 7:30 ` Pierre Muller [not found] ` <44796.6229789474$1283326243@news.gmane.org> 2010-09-01 22:35 ` Tom Tromey 2010-09-02 14:21 ` Pierre Muller 2010-09-02 15:39 ` Tom Tromey 2010-09-14 21:29 ` Tom Tromey 2010-09-15 17:20 ` Pierre Muller 2010-09-16 7:55 ` Tom Tromey 2010-09-16 9:49 ` Pierre Muller 2010-09-16 20:22 ` Tom Tromey 2010-09-16 22:31 ` Pierre Muller [not found] ` <20078.2261243605$1284672670@news.gmane.org> 2010-09-17 9:21 ` Tom Tromey 2010-09-17 13:48 ` Pierre Muller 2010-09-23 13:00 ` Tom Tromey 2010-09-23 14:48 ` Pierre Muller 2010-09-27 18:42 ` Tom Tromey 2010-09-16 17:51 ` [patch] Regression on py-prettyprint.exp: print estring [Re: Your INTERMEDIATE_ENCODING patch for Solaris] Jan Kratochvil 2010-09-16 20:33 ` Tom Tromey 2010-09-16 20:44 ` Jan Kratochvil 2010-08-18 11:52 ` Your INTERMEDIATE_ENCODING patch for Solaris Pierre Muller
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).