This is the mail archive of the
mailing list for the GDB project.
Re: displaying wchar_t in gdb
- From: Eli Zaretskii <eliz at is dot elta dot co dot il>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: Klaus-Georg Adams <Klaus-Georg dot Adams at sap dot com>, gdb at sources dot redhat dot com
- Date: Thu, 29 Nov 2001 10:18:43 +0200 (IST)
- Subject: Re: displaying wchar_t in gdb
On 28 Nov 2001, Tom Tromey wrote:
> Eli> I'm not even sure this is feasible, taking the cross-debugging
> Eli> into consideration. I guess it's possible in native debugging,
> Eli> assuming GDB and the debuggee use compatible libraries for wide
> Eli> character support, and support the same character sets.
> I think it is feasible if you assume first that the host has a
> high-powered iconv() implementation (Linux does, other systems are
> typically less good -- but there is always libiconv) and second that
> the target's wchar_t is a well-known encoding and not some peculiar
Risky assumptions, both of them (IMHO). For example, GDB can be
conceivably built with libiconv, but you cannot force the debuggee to
be built with it.
> With these assumptions the problem becomes one of telling gdb what
> encoding to expect when printing wchar_t strings. The terminal's
> encoding can just come from the current locale.
Yeah, I know all about how ``easy'' that is, from Emacs 20
> Eli> If it _is_ possible and feasible, then a special format is
> Eli> probably the way to go.
> For wchar_t I don't think you need a new `print' format (well maybe to
> specify the encoding). I think a wchar_t string could be printed
> based solely on the type, the way we print a char* string right now.
I think you need a format because a buffer can be declared `unsigned
char *' even though it holds wide characters.