This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: displaying wchar_t in gdb

>>>>> "Eli" == Eli Zaretskii <> writes:

>> What would be a strategy to implement this natively in gdb? Can you
>> tell inside gdb if we are working with wchar_t? Should there be a
>> separate format for this?

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

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.

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.

It would also be possible to print multibyte strings this way too.  In
this case you'd want a special format.

This functionality might be mildly useful for Java debugging (for Java
the problem is simpler as the target's encoding is always UCS-2).
Right now I believe we print non-ASCII characters using `\u' escapes.
I haven't yet run into a situation where this is insufficient, but I
suppose it is possible.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]