From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Tromey To: Eli Zaretskii Cc: Klaus-Georg Adams , gdb@sources.redhat.com Subject: Re: displaying wchar_t in gdb Date: Wed, 28 Nov 2001 16:02:00 -0000 Message-ID: <87u1veigta.fsf@creche.redhat.com> References: X-SW-Source: 2001-11/msg00330.html Message-ID: <20011128160200.depUixPBSbJvqPec1d51qtn3vYNcfbEJFXwlkAifHRI@z> >>>>> "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 thing. 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. Tom