From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24507 invoked by alias); 29 Nov 2001 08:19:35 -0000 Mailing-List: contact gdb-help@sourceware.cygnus.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 24485 invoked from network); 29 Nov 2001 08:19:33 -0000 Received: from unknown (HELO is.elta.co.il) (199.203.121.2) by hostedprojects.ges.redhat.com with SMTP; 29 Nov 2001 08:19:33 -0000 Received: from is (is [199.203.121.2]) by is.elta.co.il (8.9.3/8.8.8) with SMTP id KAA11228; Thu, 29 Nov 2001 10:18:43 +0200 (IST) Date: Fri, 23 Nov 2001 13:27:00 -0000 From: Eli Zaretskii X-Sender: eliz@is To: Tom Tromey cc: Klaus-Georg Adams , gdb@sources.redhat.com Subject: Re: displaying wchar_t in gdb In-Reply-To: <87u1veigta.fsf@creche.redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2001-11/txt/msg00226.txt.bz2 Message-ID: <20011123132700.Pr0SaIQVG-_Fm4anG0ijCsDUYgUF2_ukZQxGsLvpZHM@z> 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.