This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Configuring gdb_wchar.h
> Cc: gdb-patches@sources.redhat.com
> From: Tom Tromey <tromey@redhat.com>
> Date: Tue, 14 Apr 2009 10:31:13 -0600
>
> >>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
>
> Tom> Please try the appended patch.
>
> Eli> It compiles and links okay, thanks. Do you want me to test some
> Eli> feature(s) to make sure the resulting binary works as expected?
>
> Sure. If you have dejagnu, try charset.exp.
I ran some of the tests in charset.exp by hand, and I see some
potential issues.
For example, when I set the host charset to UTF-8 and the target
charset to EBCDIC-US, I get an error message:
Cannot convert between character sets `EBCDIC-US' and `UTF-8'
Is this expected? Is this again a consequence of the list of charsets
not coming from libiconv, but from the default?
Also, this result seems to be different from what charsets.exp
expects:
Breakpoint 1, main () at charset.c:173
173 }
(gdb) set host-charset ASCII
(gdb) set target-charset ISO-8859-1
(gdb) print iso_8859_1_string[69]
$2 = -94 '\242'
(gdb) print iso_8859_1_string+70
$3 = 0xbdb6 "\21"
(gdb) print iso_8859_1_string[70]
$4 = 17 '\21'
Perhaps I misunderstood, but this part of the test seems to expect
something different, at least for the second and third print commands:
# Test handling of characters in the target charset which
# can't be translated into the host charset.
if {! [string compare $target_charset iso-8859-1]} {
gdb_test "print iso_8859_1_string\[69\]" \
" = \[0-9-\]+ '\\\\242'" \
"print character with no equivalent in host character set"
gdb_test "print iso_8859_1_string + 70" \
" = ${hex} \"\\\\242.*\"" \
"print string with no equivalent in host character set"
}
I also noticed that on a GNU/Linux system, "set target-charset TAB"
shows the list of possible charsets with a ^J character at the end of
each line.