Re: displaying wchar_t in gdb

[Eli Zaretskii <eliz at is dot elta dot co dot il>]

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
> thing.

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
experience...

> 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.