RE: wchar_t encoding?

> On Wed, May 19, 2010 at 01:55:47PM -0400, Paul Koning wrote:
> > The problem is "alias for what?"
> 
> Yes - I don't know, and I'd argue, gdb shouldn't know either ;-)

I guess I didn't explain well enough.

What's going on is this: the target being debugged has strings that gdb
needs to handle.  It is told what encoding is used for those strings
(via user commands, defaulting in some suitable way).

To allow for maximum flexibility, any internal processing on those
strings is done in wchar_t form.  Some of the work involves calling
various wide char support routines, like iswprint().  Those functions
assume (perhaps implicitly) a particular encoding, perhaps ucs-4,
perhaps something else.  For example, in Solaris the answer (apparently)
is "something else and it depends on the locale".

So when GDB reads a string from the target it feeds it to iconv and asks
it to convert from whatever was specified as the target's encoding into
"the encoding that the wchar support routines expect to find in wchar_t
data".

GDB doesn't particularly want to know what that encoding is, but it has
to ask for a specific encoding or iswprint() will get the wrong answer.
This is why libiconv supports the encoding name "wchar_t" in the first
place.

If it's possible to add that encoding name to the iconv in NetBSD, that
would be a good solution.  I tried to read the iconv code and got
completely lost, so I certainly have no idea how to do that.  On the
other hand, I do know how to add code to configure.ac in gdb to teach it
to use a different name (essentially doing the aliasing in a #define in
config.h for gdb), all I need is knowledge of what to use.  Or places to
look for the answer...

	paul