displaying wchar_t in gdb

displaying wchar_t in gdb

[Klaus-Georg Adams]

Hi,
I am working on a large project in C++ which works entirely with wide
strings and streams. Is there a way to display wchar_t in gdb similar
to narrow strings?

Thanks, kga
PS: Please cc me, I'm not on the list so far.

Re: displaying wchar_t in gdb

[Eli Zaretskii]

On Mon, 26 Nov 2001, Klaus-Georg Adams wrote:

> I am working on a large project in C++ which works entirely with wide
> strings and streams. Is there a way to display wchar_t in gdb similar
> to narrow strings?

The usual technique is to have in the application a function which can 
print such strings, and then call it from GDB using the "call" command.

Re: displaying wchar_t in gdb

[Klaus-Georg Adams]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> On Mon, 26 Nov 2001, Klaus-Georg Adams wrote:
> 
> > I am working on a large project in C++ which works entirely with wide
> > strings and streams. Is there a way to display wchar_t in gdb similar
> > to narrow strings?
> 
> The usual technique is to have in the application a function which can 
> print such strings, and then call it from GDB using the "call" command.

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?

I'd be willing to explore (and maybe implement) this if somebody can
set me on the right track...

Thanks, kga

Re: displaying wchar_t in gdb

[Eli Zaretskii]

On 26 Nov 2001, Klaus-Georg Adams wrote:

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

I'm not even sure this is feasible, taking the cross-debugging into 
consideration.  I guess it's possible in native debugging, assuming GDB 
and the debuggee use compatible libraries for wide character support,
and support the same character sets.

If it _is_ possible and feasible, then a special format is probably the 
way to go.

Re: displaying wchar_t in gdb

[LeakyStain]

Ada (the programming language) supports wide characters natively, and 
the GNU Ada compiler GNAT provides a patch to gdb. I haven't checked, 
but I bet it prints wide character strings properly. So looking at the
GNAT patch to gdb would be a place to start.

-- Stephe

Eli Zaretskii wrote:
> 
> On 26 Nov 2001, Klaus-Georg Adams wrote:
> 
> > 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?
> 
> I'm not even sure this is feasible, taking the cross-debugging into
> consideration.  I guess it's possible in native debugging, assuming GDB
> and the debuggee use compatible libraries for wide character support,
> and support the same character sets.
> 
> If it _is_ possible and feasible, then a special format is probably the
> way to go.

Re: displaying wchar_t in gdb

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@is.elta.co.il> 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

Re: displaying wchar_t in gdb

[Eli Zaretskii]

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.

Re: displaying wchar_t in gdb

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@is.elta.co.il> writes:

Eli> Risky assumptions, both of them (IMHO).  For example, GDB can be
Eli> conceivably built with libiconv, but you cannot force the
Eli> debuggee to be built with it.

I don't think the debuggee would need iconv.  GDB would fetch raw
bytes from the inferior, and then transform them to the appropriate
output encoding using the host iconv.

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

Eli> I think you need a format because a buffer can be declared
Eli> `unsigned char *' even though it holds wide characters.

There's always `p (wchar_t *) buf'.
I already use this idiom with ordinary char* strings on occasion.

Tom

displaying wchar_t in gdb

[Klaus-Georg Adams]

Hi,
I am working on a large project in C++ which works entirely with wide
strings and streams. Is there a way to display wchar_t in gdb similar
to narrow strings?

Thanks, kga
PS: Please cc me, I'm not on the list so far.

Re: displaying wchar_t in gdb

[Eli Zaretskii]

On Mon, 26 Nov 2001, Klaus-Georg Adams wrote:

> I am working on a large project in C++ which works entirely with wide
> strings and streams. Is there a way to display wchar_t in gdb similar
> to narrow strings?

The usual technique is to have in the application a function which can 
print such strings, and then call it from GDB using the "call" command.

Re: displaying wchar_t in gdb

[Klaus-Georg Adams]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> On Mon, 26 Nov 2001, Klaus-Georg Adams wrote:
> 
> > I am working on a large project in C++ which works entirely with wide
> > strings and streams. Is there a way to display wchar_t in gdb similar
> > to narrow strings?
> 
> The usual technique is to have in the application a function which can 
> print such strings, and then call it from GDB using the "call" command.

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?

I'd be willing to explore (and maybe implement) this if somebody can
set me on the right track...

Thanks, kga

Re: displaying wchar_t in gdb

[Eli Zaretskii]

On 26 Nov 2001, Klaus-Georg Adams wrote:

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

I'm not even sure this is feasible, taking the cross-debugging into 
consideration.  I guess it's possible in native debugging, assuming GDB 
and the debuggee use compatible libraries for wide character support,
and support the same character sets.

If it _is_ possible and feasible, then a special format is probably the 
way to go.

Re: displaying wchar_t in gdb

[LeakyStain]

Ada (the programming language) supports wide characters natively, and 
the GNU Ada compiler GNAT provides a patch to gdb. I haven't checked, 
but I bet it prints wide character strings properly. So looking at the
GNAT patch to gdb would be a place to start.

-- Stephe

Eli Zaretskii wrote:
> 
> On 26 Nov 2001, Klaus-Georg Adams wrote:
> 
> > 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?
> 
> I'm not even sure this is feasible, taking the cross-debugging into
> consideration.  I guess it's possible in native debugging, assuming GDB
> and the debuggee use compatible libraries for wide character support,
> and support the same character sets.
> 
> If it _is_ possible and feasible, then a special format is probably the
> way to go.

Re: displaying wchar_t in gdb

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@is.elta.co.il> 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

Re: displaying wchar_t in gdb

[Eli Zaretskii]

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.

Re: displaying wchar_t in gdb

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@is.elta.co.il> writes:

Eli> Risky assumptions, both of them (IMHO).  For example, GDB can be
Eli> conceivably built with libiconv, but you cannot force the
Eli> debuggee to be built with it.

I don't think the debuggee would need iconv.  GDB would fetch raw
bytes from the inferior, and then transform them to the appropriate
output encoding using the host iconv.

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

Eli> I think you need a format because a buffer can be declared
Eli> `unsigned char *' even though it holds wide characters.

There's always `p (wchar_t *) buf'.
I already use this idiom with ordinary char* strings on occasion.

Tom

Re: displaying wchar_t in gdb

[Paul Hilfinger]

Well, a note of caution.  We do have code for wide *Ada* strings, but
these have an Ada-specific representation (and an Ada-specific output
format for the non-ASCII stuff), and I don't know that the code will
be directly useful to you.  Nevertheless, welcome to it.

Paul Hilfinger

Re: displaying wchar_t in gdb

[Joel Brobecker]

> I have tried to locate that patch but was unsucessful. Could you point
> me to the right place?

You can find this patch in the GNAT 3.13p sources. One possible location
for the sources is ftp://ftp.cs.nyu.edu:/pub/gnat/3.13p/gnat-3.13p-src.tgz

Enjoy,
-- 
Joel

Re: displaying wchar_t in gdb

[Arnaud Charlet]

> I have tried to locate that patch but was unsucessful. Could you point
> me to the right place?

We are about to submit our patches. They are currently not suitable for
direct inclusion in CVS, and we have a version based on a pre 5.1 snapshot,
but that should be good enough as a starting point.

Paul Hilfinger will send a message as to where to find our latest patch.

Arno

Re: displaying wchar_t in gdb

[Klaus-Georg Adams]

Stephe wrote:

> Ada (the programming language) supports wide characters natively, and 
> the GNU Ada compiler GNAT provides a patch to gdb. I haven't checked, 
> but I bet it prints wide character strings properly. So looking at the
> GNAT patch to gdb would be a place to start.

Hi,
I have tried to locate that patch but was unsucessful. Could you point
me to the right place?

Thanks!
Regards, kga

Re: displaying wchar_t in gdb

[Paul Hilfinger]

Well, a note of caution.  We do have code for wide *Ada* strings, but
these have an Ada-specific representation (and an Ada-specific output
format for the non-ASCII stuff), and I don't know that the code will
be directly useful to you.  Nevertheless, welcome to it.

Paul Hilfinger

Re: displaying wchar_t in gdb

[Joel Brobecker]

> I have tried to locate that patch but was unsucessful. Could you point
> me to the right place?

You can find this patch in the GNAT 3.13p sources. One possible location
for the sources is ftp://ftp.cs.nyu.edu:/pub/gnat/3.13p/gnat-3.13p-src.tgz

Enjoy,
-- 
Joel

Re: displaying wchar_t in gdb

[Arnaud Charlet]

> I have tried to locate that patch but was unsucessful. Could you point
> me to the right place?

We are about to submit our patches. They are currently not suitable for
direct inclusion in CVS, and we have a version based on a pre 5.1 snapshot,
but that should be good enough as a starting point.

Paul Hilfinger will send a message as to where to find our latest patch.

Arno

Re: displaying wchar_t in gdb

[Klaus-Georg Adams]

Stephe wrote:

> Ada (the programming language) supports wide characters natively, and 
> the GNU Ada compiler GNAT provides a patch to gdb. I haven't checked, 
> but I bet it prints wide character strings properly. So looking at the
> GNAT patch to gdb would be a place to start.

Hi,
I have tried to locate that patch but was unsucessful. Could you point
me to the right place?

Thanks!
Regards, kga