binutils-gdb/gdb/testsuite/gdb.cp/wide_char_types.exp

182 lines
5.8 KiB
Plaintext
Raw Normal View History

Fix PR c++/21323: GDB thinks char16_t and char32_t are signed in C++ While the C++ standard says that char16_t and char32_t are unsigned types: Types char16_t and char32_t denote distinct types with the same size, signedness, and alignment as uint_least16_t and uint_least32_t, respectively, in <cstdint>, called the underlying types. ... gdb treats them as signed currently: (gdb) p (char16_t)-1 $1 = -1 u'\xffff' There are actually two places in gdb that hardcode these types: - gdbtypes.c:gdbtypes_post_init, when creating the built-in types, seemingly used by the "x /s" command (judging from commit 9a22f0d0). - dwarf2read.c, when reading base types with DW_ATE_UTF encoding (which is what is used for these types, when compiling for C++11 and up). Despite the comment, the type created does end up used. Both places need fixing. But since I couldn't tell why dwarf2read.c needs to create a new type, I've made it use the per-arch built-in types instead, so that the types are only created once per arch instead of once per objfile. That seems to work fine. While writting the test, I noticed that the C++ language parser isn't actually aware of these built-in types, so if you try to use them without a program that uses them, you get: (gdb) set language c++ (gdb) ptype char16_t No symbol table is loaded. Use the "file" command. (gdb) ptype u"hello" No type named char16_t. (gdb) p u"hello" No type named char16_t. That's fixed by simply adding a couple entries to C++'s built-in types array in c-lang.c. With that, we get the expected: (gdb) ptype char16_t type = char16_t (gdb) ptype u"hello" type = char16_t [6] (gdb) p u"hello" $1 = u"hello" gdb/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR c++/21323 * c-lang.c (cplus_primitive_types) <cplus_primitive_type_char16_t, cplus_primitive_type_char32_t>: New enum values. (cplus_language_arch_info): Register cplus_primitive_type_char16_t and cplus_primitive_type_char32_t. * dwarf2read.c (read_base_type) <DW_ATE_UTF>: If bit size is 16 or 32, use the archtecture's built-in type for char16_t and char32_t, respectively. Otherwise, fallback to init_integer_type as before, but make the type unsigned, and issue a complaint. * gdbtypes.c (gdbtypes_post_init): Make char16_t and char32_t unsigned. gdb/testsuite/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR c++/21323 * gdb.cp/wide_char_types.c: New file. * gdb.cp/wide_char_types.exp: New file.
2017-04-12 15:00:49 +02:00
# This testcase is part of GDB, the GNU debugger.
# Copyright 2017-2018 Free Software Foundation, Inc.
Fix PR c++/21323: GDB thinks char16_t and char32_t are signed in C++ While the C++ standard says that char16_t and char32_t are unsigned types: Types char16_t and char32_t denote distinct types with the same size, signedness, and alignment as uint_least16_t and uint_least32_t, respectively, in <cstdint>, called the underlying types. ... gdb treats them as signed currently: (gdb) p (char16_t)-1 $1 = -1 u'\xffff' There are actually two places in gdb that hardcode these types: - gdbtypes.c:gdbtypes_post_init, when creating the built-in types, seemingly used by the "x /s" command (judging from commit 9a22f0d0). - dwarf2read.c, when reading base types with DW_ATE_UTF encoding (which is what is used for these types, when compiling for C++11 and up). Despite the comment, the type created does end up used. Both places need fixing. But since I couldn't tell why dwarf2read.c needs to create a new type, I've made it use the per-arch built-in types instead, so that the types are only created once per arch instead of once per objfile. That seems to work fine. While writting the test, I noticed that the C++ language parser isn't actually aware of these built-in types, so if you try to use them without a program that uses them, you get: (gdb) set language c++ (gdb) ptype char16_t No symbol table is loaded. Use the "file" command. (gdb) ptype u"hello" No type named char16_t. (gdb) p u"hello" No type named char16_t. That's fixed by simply adding a couple entries to C++'s built-in types array in c-lang.c. With that, we get the expected: (gdb) ptype char16_t type = char16_t (gdb) ptype u"hello" type = char16_t [6] (gdb) p u"hello" $1 = u"hello" gdb/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR c++/21323 * c-lang.c (cplus_primitive_types) <cplus_primitive_type_char16_t, cplus_primitive_type_char32_t>: New enum values. (cplus_language_arch_info): Register cplus_primitive_type_char16_t and cplus_primitive_type_char32_t. * dwarf2read.c (read_base_type) <DW_ATE_UTF>: If bit size is 16 or 32, use the archtecture's built-in type for char16_t and char32_t, respectively. Otherwise, fallback to init_integer_type as before, but make the type unsigned, and issue a complaint. * gdbtypes.c (gdbtypes_post_init): Make char16_t and char32_t unsigned. gdb/testsuite/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR c++/21323 * gdb.cp/wide_char_types.c: New file. * gdb.cp/wide_char_types.exp: New file.
2017-04-12 15:00:49 +02:00
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
Teach GDB that wchar_t is a built-in type in C++ mode GDB is currently not aware that wchar_t is a built-in type in C++ mode. This is usually not a problem because the debug info describes the type, so when you have a program loaded, you don't notice this. However, if you try expressions involving wchar_t before a program is loaded, gdb errors out: (gdb) p (wchar_t)-1 No symbol table is loaded. Use the "file" command. (gdb) p L"hello" No type named wchar_t. (gdb) ptype L"hello" No type named wchar_t. This commit teaches gdb about the type. After: (gdb) p (wchar_t)-1 $1 = -1 L'\xffffffff' (gdb) p L"hello" $2 = L"hello" (gdb) ptype L"hello" type = wchar_t [6] Unlike char16_t/char32_t, unfortunately, the underlying type of wchar_t is implementation dependent, both size and signness. So this requires adding a couple new gdbarch hooks. I grepped the GCC code base for WCHAR_TYPE and WCHAR_TYPE_SIZE, and it seems to me that the majority of the ABIs have a 4-byte signed wchar_t, so that's what I made the default for GDB too. And then I looked for which ports have a 16-bit and/or unsigned wchar_t, and made GDB follow suit. gdb/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR gdb/21323 * c-lang.c (cplus_primitive_types) <cplus_primitive_type_wchar_t>: New enum value. (cplus_language_arch_info): Register cplus_primitive_type_wchar_t. * gdbtypes.h (struct builtin_type) <builtin_wchar>: New field. * gdbtypes.c (gdbtypes_post_init): Create the "wchar_t" type. * gdbarch.sh (wchar_bit, wchar_signed): New per-arch values. * gdbarch.h, gdbarch.c: Regenerate. * aarch64-tdep.c (aarch64_gdbarch_init): Override gdbarch_wchar_bit and gdbarch_wchar_signed. * alpha-tdep.c (alpha_gdbarch_init): Likewise. * arm-tdep.c (arm_gdbarch_init): Likewise. * avr-tdep.c (avr_gdbarch_init): Likewise. * h8300-tdep.c (h8300_gdbarch_init): Likewise. * i386-nto-tdep.c (i386nto_init_abi): Likewise. * i386-tdep.c (i386_go32_init_abi): Likewise. * m32r-tdep.c (m32r_gdbarch_init): Likewise. * moxie-tdep.c (moxie_gdbarch_init): Likewise. * nds32-tdep.c (nds32_gdbarch_init): Likewise. * rs6000-aix-tdep.c (rs6000_aix_init_osabi): Likewise. * sh-tdep.c (sh_gdbarch_init): Likewise. * sparc-tdep.c (sparc32_gdbarch_init): Likewise. * sparc64-tdep.c (sparc64_init_abi): Likewise. * windows-tdep.c (windows_init_abi): Likewise. * xstormy16-tdep.c (xstormy16_gdbarch_init): Likewise. gdb/testsuite/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR gdb/21323 * gdb.cp/wide_char_types.c: Include <wchar.h>. (wchar): New global. * gdb.cp/wide_char_types.exp (wide_char_types_program) (do_test_wide_char, wide_char_types_no_program, top level): Add wchar_t testing.
2017-04-12 15:00:49 +02:00
# Test GDB's awareness of the wchar_t (C++98+) and char16_t, char32_t
# (C++11+) built-in types. We also run most tests here in C mode, and
# check whether the built-ins are disabled (gdb uses the typedefs in
# the debug info instead.)
Fix PR c++/21323: GDB thinks char16_t and char32_t are signed in C++ While the C++ standard says that char16_t and char32_t are unsigned types: Types char16_t and char32_t denote distinct types with the same size, signedness, and alignment as uint_least16_t and uint_least32_t, respectively, in <cstdint>, called the underlying types. ... gdb treats them as signed currently: (gdb) p (char16_t)-1 $1 = -1 u'\xffff' There are actually two places in gdb that hardcode these types: - gdbtypes.c:gdbtypes_post_init, when creating the built-in types, seemingly used by the "x /s" command (judging from commit 9a22f0d0). - dwarf2read.c, when reading base types with DW_ATE_UTF encoding (which is what is used for these types, when compiling for C++11 and up). Despite the comment, the type created does end up used. Both places need fixing. But since I couldn't tell why dwarf2read.c needs to create a new type, I've made it use the per-arch built-in types instead, so that the types are only created once per arch instead of once per objfile. That seems to work fine. While writting the test, I noticed that the C++ language parser isn't actually aware of these built-in types, so if you try to use them without a program that uses them, you get: (gdb) set language c++ (gdb) ptype char16_t No symbol table is loaded. Use the "file" command. (gdb) ptype u"hello" No type named char16_t. (gdb) p u"hello" No type named char16_t. That's fixed by simply adding a couple entries to C++'s built-in types array in c-lang.c. With that, we get the expected: (gdb) ptype char16_t type = char16_t (gdb) ptype u"hello" type = char16_t [6] (gdb) p u"hello" $1 = u"hello" gdb/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR c++/21323 * c-lang.c (cplus_primitive_types) <cplus_primitive_type_char16_t, cplus_primitive_type_char32_t>: New enum values. (cplus_language_arch_info): Register cplus_primitive_type_char16_t and cplus_primitive_type_char32_t. * dwarf2read.c (read_base_type) <DW_ATE_UTF>: If bit size is 16 or 32, use the archtecture's built-in type for char16_t and char32_t, respectively. Otherwise, fallback to init_integer_type as before, but make the type unsigned, and issue a complaint. * gdbtypes.c (gdbtypes_post_init): Make char16_t and char32_t unsigned. gdb/testsuite/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR c++/21323 * gdb.cp/wide_char_types.c: New file. * gdb.cp/wide_char_types.exp: New file.
2017-04-12 15:00:49 +02:00
standard_testfile
Teach GDB that wchar_t is a built-in type in C++ mode GDB is currently not aware that wchar_t is a built-in type in C++ mode. This is usually not a problem because the debug info describes the type, so when you have a program loaded, you don't notice this. However, if you try expressions involving wchar_t before a program is loaded, gdb errors out: (gdb) p (wchar_t)-1 No symbol table is loaded. Use the "file" command. (gdb) p L"hello" No type named wchar_t. (gdb) ptype L"hello" No type named wchar_t. This commit teaches gdb about the type. After: (gdb) p (wchar_t)-1 $1 = -1 L'\xffffffff' (gdb) p L"hello" $2 = L"hello" (gdb) ptype L"hello" type = wchar_t [6] Unlike char16_t/char32_t, unfortunately, the underlying type of wchar_t is implementation dependent, both size and signness. So this requires adding a couple new gdbarch hooks. I grepped the GCC code base for WCHAR_TYPE and WCHAR_TYPE_SIZE, and it seems to me that the majority of the ABIs have a 4-byte signed wchar_t, so that's what I made the default for GDB too. And then I looked for which ports have a 16-bit and/or unsigned wchar_t, and made GDB follow suit. gdb/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR gdb/21323 * c-lang.c (cplus_primitive_types) <cplus_primitive_type_wchar_t>: New enum value. (cplus_language_arch_info): Register cplus_primitive_type_wchar_t. * gdbtypes.h (struct builtin_type) <builtin_wchar>: New field. * gdbtypes.c (gdbtypes_post_init): Create the "wchar_t" type. * gdbarch.sh (wchar_bit, wchar_signed): New per-arch values. * gdbarch.h, gdbarch.c: Regenerate. * aarch64-tdep.c (aarch64_gdbarch_init): Override gdbarch_wchar_bit and gdbarch_wchar_signed. * alpha-tdep.c (alpha_gdbarch_init): Likewise. * arm-tdep.c (arm_gdbarch_init): Likewise. * avr-tdep.c (avr_gdbarch_init): Likewise. * h8300-tdep.c (h8300_gdbarch_init): Likewise. * i386-nto-tdep.c (i386nto_init_abi): Likewise. * i386-tdep.c (i386_go32_init_abi): Likewise. * m32r-tdep.c (m32r_gdbarch_init): Likewise. * moxie-tdep.c (moxie_gdbarch_init): Likewise. * nds32-tdep.c (nds32_gdbarch_init): Likewise. * rs6000-aix-tdep.c (rs6000_aix_init_osabi): Likewise. * sh-tdep.c (sh_gdbarch_init): Likewise. * sparc-tdep.c (sparc32_gdbarch_init): Likewise. * sparc64-tdep.c (sparc64_init_abi): Likewise. * windows-tdep.c (windows_init_abi): Likewise. * xstormy16-tdep.c (xstormy16_gdbarch_init): Likewise. gdb/testsuite/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR gdb/21323 * gdb.cp/wide_char_types.c: Include <wchar.h>. (wchar): New global. * gdb.cp/wide_char_types.exp (wide_char_types_program) (do_test_wide_char, wide_char_types_no_program, top level): Add wchar_t testing.
2017-04-12 15:00:49 +02:00
# Test char16_t/char32_t/wchar_t in language LANG, against symbols in
Fix PR c++/21323: GDB thinks char16_t and char32_t are signed in C++ While the C++ standard says that char16_t and char32_t are unsigned types: Types char16_t and char32_t denote distinct types with the same size, signedness, and alignment as uint_least16_t and uint_least32_t, respectively, in <cstdint>, called the underlying types. ... gdb treats them as signed currently: (gdb) p (char16_t)-1 $1 = -1 u'\xffff' There are actually two places in gdb that hardcode these types: - gdbtypes.c:gdbtypes_post_init, when creating the built-in types, seemingly used by the "x /s" command (judging from commit 9a22f0d0). - dwarf2read.c, when reading base types with DW_ATE_UTF encoding (which is what is used for these types, when compiling for C++11 and up). Despite the comment, the type created does end up used. Both places need fixing. But since I couldn't tell why dwarf2read.c needs to create a new type, I've made it use the per-arch built-in types instead, so that the types are only created once per arch instead of once per objfile. That seems to work fine. While writting the test, I noticed that the C++ language parser isn't actually aware of these built-in types, so if you try to use them without a program that uses them, you get: (gdb) set language c++ (gdb) ptype char16_t No symbol table is loaded. Use the "file" command. (gdb) ptype u"hello" No type named char16_t. (gdb) p u"hello" No type named char16_t. That's fixed by simply adding a couple entries to C++'s built-in types array in c-lang.c. With that, we get the expected: (gdb) ptype char16_t type = char16_t (gdb) ptype u"hello" type = char16_t [6] (gdb) p u"hello" $1 = u"hello" gdb/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR c++/21323 * c-lang.c (cplus_primitive_types) <cplus_primitive_type_char16_t, cplus_primitive_type_char32_t>: New enum values. (cplus_language_arch_info): Register cplus_primitive_type_char16_t and cplus_primitive_type_char32_t. * dwarf2read.c (read_base_type) <DW_ATE_UTF>: If bit size is 16 or 32, use the archtecture's built-in type for char16_t and char32_t, respectively. Otherwise, fallback to init_integer_type as before, but make the type unsigned, and issue a complaint. * gdbtypes.c (gdbtypes_post_init): Make char16_t and char32_t unsigned. gdb/testsuite/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR c++/21323 * gdb.cp/wide_char_types.c: New file. * gdb.cp/wide_char_types.exp: New file.
2017-04-12 15:00:49 +02:00
# a program. Lang can be "c", "c++03" or "c++11". In C++11,
# char16_t/char32_t are built-in types, and the debug information
# reflects that (see
# http://wiki.dwarfstd.org/index.php?title=C%2B%2B0x:_New_string_literals).
proc wide_char_types_program {lang} {
global srcfile testfile
set options {debug}
if {$lang == "c++03"} {
lappend options c++ additional_flags=-std=c++03
set out $testfile-cxx03
} elseif {$lang == "c++11"} {
lappend options c++ additional_flags=-std=c++11
set out $testfile-cxx11
} else {
set out $testfile-c
}
if { [prepare_for_testing "failed to prepare" \
${out} [list $srcfile] $options] } {
return -1
}
if ![runto_main] then {
fail "can't run to main"
return 0
}
Teach GDB that wchar_t is a built-in type in C++ mode GDB is currently not aware that wchar_t is a built-in type in C++ mode. This is usually not a problem because the debug info describes the type, so when you have a program loaded, you don't notice this. However, if you try expressions involving wchar_t before a program is loaded, gdb errors out: (gdb) p (wchar_t)-1 No symbol table is loaded. Use the "file" command. (gdb) p L"hello" No type named wchar_t. (gdb) ptype L"hello" No type named wchar_t. This commit teaches gdb about the type. After: (gdb) p (wchar_t)-1 $1 = -1 L'\xffffffff' (gdb) p L"hello" $2 = L"hello" (gdb) ptype L"hello" type = wchar_t [6] Unlike char16_t/char32_t, unfortunately, the underlying type of wchar_t is implementation dependent, both size and signness. So this requires adding a couple new gdbarch hooks. I grepped the GCC code base for WCHAR_TYPE and WCHAR_TYPE_SIZE, and it seems to me that the majority of the ABIs have a 4-byte signed wchar_t, so that's what I made the default for GDB too. And then I looked for which ports have a 16-bit and/or unsigned wchar_t, and made GDB follow suit. gdb/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR gdb/21323 * c-lang.c (cplus_primitive_types) <cplus_primitive_type_wchar_t>: New enum value. (cplus_language_arch_info): Register cplus_primitive_type_wchar_t. * gdbtypes.h (struct builtin_type) <builtin_wchar>: New field. * gdbtypes.c (gdbtypes_post_init): Create the "wchar_t" type. * gdbarch.sh (wchar_bit, wchar_signed): New per-arch values. * gdbarch.h, gdbarch.c: Regenerate. * aarch64-tdep.c (aarch64_gdbarch_init): Override gdbarch_wchar_bit and gdbarch_wchar_signed. * alpha-tdep.c (alpha_gdbarch_init): Likewise. * arm-tdep.c (arm_gdbarch_init): Likewise. * avr-tdep.c (avr_gdbarch_init): Likewise. * h8300-tdep.c (h8300_gdbarch_init): Likewise. * i386-nto-tdep.c (i386nto_init_abi): Likewise. * i386-tdep.c (i386_go32_init_abi): Likewise. * m32r-tdep.c (m32r_gdbarch_init): Likewise. * moxie-tdep.c (moxie_gdbarch_init): Likewise. * nds32-tdep.c (nds32_gdbarch_init): Likewise. * rs6000-aix-tdep.c (rs6000_aix_init_osabi): Likewise. * sh-tdep.c (sh_gdbarch_init): Likewise. * sparc-tdep.c (sparc32_gdbarch_init): Likewise. * sparc64-tdep.c (sparc64_init_abi): Likewise. * windows-tdep.c (windows_init_abi): Likewise. * xstormy16-tdep.c (xstormy16_gdbarch_init): Likewise. gdb/testsuite/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR gdb/21323 * gdb.cp/wide_char_types.c: Include <wchar.h>. (wchar): New global. * gdb.cp/wide_char_types.exp (wide_char_types_program) (do_test_wide_char, wide_char_types_no_program, top level): Add wchar_t testing.
2017-04-12 15:00:49 +02:00
do_test_wide_char $lang "u16" "u32" "wchar"
Fix PR c++/21323: GDB thinks char16_t and char32_t are signed in C++ While the C++ standard says that char16_t and char32_t are unsigned types: Types char16_t and char32_t denote distinct types with the same size, signedness, and alignment as uint_least16_t and uint_least32_t, respectively, in <cstdint>, called the underlying types. ... gdb treats them as signed currently: (gdb) p (char16_t)-1 $1 = -1 u'\xffff' There are actually two places in gdb that hardcode these types: - gdbtypes.c:gdbtypes_post_init, when creating the built-in types, seemingly used by the "x /s" command (judging from commit 9a22f0d0). - dwarf2read.c, when reading base types with DW_ATE_UTF encoding (which is what is used for these types, when compiling for C++11 and up). Despite the comment, the type created does end up used. Both places need fixing. But since I couldn't tell why dwarf2read.c needs to create a new type, I've made it use the per-arch built-in types instead, so that the types are only created once per arch instead of once per objfile. That seems to work fine. While writting the test, I noticed that the C++ language parser isn't actually aware of these built-in types, so if you try to use them without a program that uses them, you get: (gdb) set language c++ (gdb) ptype char16_t No symbol table is loaded. Use the "file" command. (gdb) ptype u"hello" No type named char16_t. (gdb) p u"hello" No type named char16_t. That's fixed by simply adding a couple entries to C++'s built-in types array in c-lang.c. With that, we get the expected: (gdb) ptype char16_t type = char16_t (gdb) ptype u"hello" type = char16_t [6] (gdb) p u"hello" $1 = u"hello" gdb/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR c++/21323 * c-lang.c (cplus_primitive_types) <cplus_primitive_type_char16_t, cplus_primitive_type_char32_t>: New enum values. (cplus_language_arch_info): Register cplus_primitive_type_char16_t and cplus_primitive_type_char32_t. * dwarf2read.c (read_base_type) <DW_ATE_UTF>: If bit size is 16 or 32, use the archtecture's built-in type for char16_t and char32_t, respectively. Otherwise, fallback to init_integer_type as before, but make the type unsigned, and issue a complaint. * gdbtypes.c (gdbtypes_post_init): Make char16_t and char32_t unsigned. gdb/testsuite/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR c++/21323 * gdb.cp/wide_char_types.c: New file. * gdb.cp/wide_char_types.exp: New file.
2017-04-12 15:00:49 +02:00
}
Teach GDB that wchar_t is a built-in type in C++ mode GDB is currently not aware that wchar_t is a built-in type in C++ mode. This is usually not a problem because the debug info describes the type, so when you have a program loaded, you don't notice this. However, if you try expressions involving wchar_t before a program is loaded, gdb errors out: (gdb) p (wchar_t)-1 No symbol table is loaded. Use the "file" command. (gdb) p L"hello" No type named wchar_t. (gdb) ptype L"hello" No type named wchar_t. This commit teaches gdb about the type. After: (gdb) p (wchar_t)-1 $1 = -1 L'\xffffffff' (gdb) p L"hello" $2 = L"hello" (gdb) ptype L"hello" type = wchar_t [6] Unlike char16_t/char32_t, unfortunately, the underlying type of wchar_t is implementation dependent, both size and signness. So this requires adding a couple new gdbarch hooks. I grepped the GCC code base for WCHAR_TYPE and WCHAR_TYPE_SIZE, and it seems to me that the majority of the ABIs have a 4-byte signed wchar_t, so that's what I made the default for GDB too. And then I looked for which ports have a 16-bit and/or unsigned wchar_t, and made GDB follow suit. gdb/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR gdb/21323 * c-lang.c (cplus_primitive_types) <cplus_primitive_type_wchar_t>: New enum value. (cplus_language_arch_info): Register cplus_primitive_type_wchar_t. * gdbtypes.h (struct builtin_type) <builtin_wchar>: New field. * gdbtypes.c (gdbtypes_post_init): Create the "wchar_t" type. * gdbarch.sh (wchar_bit, wchar_signed): New per-arch values. * gdbarch.h, gdbarch.c: Regenerate. * aarch64-tdep.c (aarch64_gdbarch_init): Override gdbarch_wchar_bit and gdbarch_wchar_signed. * alpha-tdep.c (alpha_gdbarch_init): Likewise. * arm-tdep.c (arm_gdbarch_init): Likewise. * avr-tdep.c (avr_gdbarch_init): Likewise. * h8300-tdep.c (h8300_gdbarch_init): Likewise. * i386-nto-tdep.c (i386nto_init_abi): Likewise. * i386-tdep.c (i386_go32_init_abi): Likewise. * m32r-tdep.c (m32r_gdbarch_init): Likewise. * moxie-tdep.c (moxie_gdbarch_init): Likewise. * nds32-tdep.c (nds32_gdbarch_init): Likewise. * rs6000-aix-tdep.c (rs6000_aix_init_osabi): Likewise. * sh-tdep.c (sh_gdbarch_init): Likewise. * sparc-tdep.c (sparc32_gdbarch_init): Likewise. * sparc64-tdep.c (sparc64_init_abi): Likewise. * windows-tdep.c (windows_init_abi): Likewise. * xstormy16-tdep.c (xstormy16_gdbarch_init): Likewise. gdb/testsuite/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR gdb/21323 * gdb.cp/wide_char_types.c: Include <wchar.h>. (wchar): New global. * gdb.cp/wide_char_types.exp (wide_char_types_program) (do_test_wide_char, wide_char_types_no_program, top level): Add wchar_t testing.
2017-04-12 15:00:49 +02:00
# Test char16_t/char32_t/wchar_t in language LANG. Use CHAR16_EXP,
# CHAR32_EXP, and WCHAR_EXP as expression for each of the
# corresponding types. (E.g., CHAR16_EXP will be u16 when testing
# against the program, and "(char16_t)-1" when testing the built-in
# types without a program loaded.)
Fix PR c++/21323: GDB thinks char16_t and char32_t are signed in C++ While the C++ standard says that char16_t and char32_t are unsigned types: Types char16_t and char32_t denote distinct types with the same size, signedness, and alignment as uint_least16_t and uint_least32_t, respectively, in <cstdint>, called the underlying types. ... gdb treats them as signed currently: (gdb) p (char16_t)-1 $1 = -1 u'\xffff' There are actually two places in gdb that hardcode these types: - gdbtypes.c:gdbtypes_post_init, when creating the built-in types, seemingly used by the "x /s" command (judging from commit 9a22f0d0). - dwarf2read.c, when reading base types with DW_ATE_UTF encoding (which is what is used for these types, when compiling for C++11 and up). Despite the comment, the type created does end up used. Both places need fixing. But since I couldn't tell why dwarf2read.c needs to create a new type, I've made it use the per-arch built-in types instead, so that the types are only created once per arch instead of once per objfile. That seems to work fine. While writting the test, I noticed that the C++ language parser isn't actually aware of these built-in types, so if you try to use them without a program that uses them, you get: (gdb) set language c++ (gdb) ptype char16_t No symbol table is loaded. Use the "file" command. (gdb) ptype u"hello" No type named char16_t. (gdb) p u"hello" No type named char16_t. That's fixed by simply adding a couple entries to C++'s built-in types array in c-lang.c. With that, we get the expected: (gdb) ptype char16_t type = char16_t (gdb) ptype u"hello" type = char16_t [6] (gdb) p u"hello" $1 = u"hello" gdb/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR c++/21323 * c-lang.c (cplus_primitive_types) <cplus_primitive_type_char16_t, cplus_primitive_type_char32_t>: New enum values. (cplus_language_arch_info): Register cplus_primitive_type_char16_t and cplus_primitive_type_char32_t. * dwarf2read.c (read_base_type) <DW_ATE_UTF>: If bit size is 16 or 32, use the archtecture's built-in type for char16_t and char32_t, respectively. Otherwise, fallback to init_integer_type as before, but make the type unsigned, and issue a complaint. * gdbtypes.c (gdbtypes_post_init): Make char16_t and char32_t unsigned. gdb/testsuite/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR c++/21323 * gdb.cp/wide_char_types.c: New file. * gdb.cp/wide_char_types.exp: New file.
2017-04-12 15:00:49 +02:00
Teach GDB that wchar_t is a built-in type in C++ mode GDB is currently not aware that wchar_t is a built-in type in C++ mode. This is usually not a problem because the debug info describes the type, so when you have a program loaded, you don't notice this. However, if you try expressions involving wchar_t before a program is loaded, gdb errors out: (gdb) p (wchar_t)-1 No symbol table is loaded. Use the "file" command. (gdb) p L"hello" No type named wchar_t. (gdb) ptype L"hello" No type named wchar_t. This commit teaches gdb about the type. After: (gdb) p (wchar_t)-1 $1 = -1 L'\xffffffff' (gdb) p L"hello" $2 = L"hello" (gdb) ptype L"hello" type = wchar_t [6] Unlike char16_t/char32_t, unfortunately, the underlying type of wchar_t is implementation dependent, both size and signness. So this requires adding a couple new gdbarch hooks. I grepped the GCC code base for WCHAR_TYPE and WCHAR_TYPE_SIZE, and it seems to me that the majority of the ABIs have a 4-byte signed wchar_t, so that's what I made the default for GDB too. And then I looked for which ports have a 16-bit and/or unsigned wchar_t, and made GDB follow suit. gdb/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR gdb/21323 * c-lang.c (cplus_primitive_types) <cplus_primitive_type_wchar_t>: New enum value. (cplus_language_arch_info): Register cplus_primitive_type_wchar_t. * gdbtypes.h (struct builtin_type) <builtin_wchar>: New field. * gdbtypes.c (gdbtypes_post_init): Create the "wchar_t" type. * gdbarch.sh (wchar_bit, wchar_signed): New per-arch values. * gdbarch.h, gdbarch.c: Regenerate. * aarch64-tdep.c (aarch64_gdbarch_init): Override gdbarch_wchar_bit and gdbarch_wchar_signed. * alpha-tdep.c (alpha_gdbarch_init): Likewise. * arm-tdep.c (arm_gdbarch_init): Likewise. * avr-tdep.c (avr_gdbarch_init): Likewise. * h8300-tdep.c (h8300_gdbarch_init): Likewise. * i386-nto-tdep.c (i386nto_init_abi): Likewise. * i386-tdep.c (i386_go32_init_abi): Likewise. * m32r-tdep.c (m32r_gdbarch_init): Likewise. * moxie-tdep.c (moxie_gdbarch_init): Likewise. * nds32-tdep.c (nds32_gdbarch_init): Likewise. * rs6000-aix-tdep.c (rs6000_aix_init_osabi): Likewise. * sh-tdep.c (sh_gdbarch_init): Likewise. * sparc-tdep.c (sparc32_gdbarch_init): Likewise. * sparc64-tdep.c (sparc64_init_abi): Likewise. * windows-tdep.c (windows_init_abi): Likewise. * xstormy16-tdep.c (xstormy16_gdbarch_init): Likewise. gdb/testsuite/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR gdb/21323 * gdb.cp/wide_char_types.c: Include <wchar.h>. (wchar): New global. * gdb.cp/wide_char_types.exp (wide_char_types_program) (do_test_wide_char, wide_char_types_no_program, top level): Add wchar_t testing.
2017-04-12 15:00:49 +02:00
proc do_test_wide_char {lang char16_exp char32_exp wchar_exp} {
Fix PR c++/21323: GDB thinks char16_t and char32_t are signed in C++ While the C++ standard says that char16_t and char32_t are unsigned types: Types char16_t and char32_t denote distinct types with the same size, signedness, and alignment as uint_least16_t and uint_least32_t, respectively, in <cstdint>, called the underlying types. ... gdb treats them as signed currently: (gdb) p (char16_t)-1 $1 = -1 u'\xffff' There are actually two places in gdb that hardcode these types: - gdbtypes.c:gdbtypes_post_init, when creating the built-in types, seemingly used by the "x /s" command (judging from commit 9a22f0d0). - dwarf2read.c, when reading base types with DW_ATE_UTF encoding (which is what is used for these types, when compiling for C++11 and up). Despite the comment, the type created does end up used. Both places need fixing. But since I couldn't tell why dwarf2read.c needs to create a new type, I've made it use the per-arch built-in types instead, so that the types are only created once per arch instead of once per objfile. That seems to work fine. While writting the test, I noticed that the C++ language parser isn't actually aware of these built-in types, so if you try to use them without a program that uses them, you get: (gdb) set language c++ (gdb) ptype char16_t No symbol table is loaded. Use the "file" command. (gdb) ptype u"hello" No type named char16_t. (gdb) p u"hello" No type named char16_t. That's fixed by simply adding a couple entries to C++'s built-in types array in c-lang.c. With that, we get the expected: (gdb) ptype char16_t type = char16_t (gdb) ptype u"hello" type = char16_t [6] (gdb) p u"hello" $1 = u"hello" gdb/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR c++/21323 * c-lang.c (cplus_primitive_types) <cplus_primitive_type_char16_t, cplus_primitive_type_char32_t>: New enum values. (cplus_language_arch_info): Register cplus_primitive_type_char16_t and cplus_primitive_type_char32_t. * dwarf2read.c (read_base_type) <DW_ATE_UTF>: If bit size is 16 or 32, use the archtecture's built-in type for char16_t and char32_t, respectively. Otherwise, fallback to init_integer_type as before, but make the type unsigned, and issue a complaint. * gdbtypes.c (gdbtypes_post_init): Make char16_t and char32_t unsigned. gdb/testsuite/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR c++/21323 * gdb.cp/wide_char_types.c: New file. * gdb.cp/wide_char_types.exp: New file.
2017-04-12 15:00:49 +02:00
global gdb_prompt
# Check that the fixed-width wide types are distinct built-in
# types in C++11+. In other modes, they're instead typedefs,
# found in the debug info.
if {$lang == "c++11"} {
gdb_test "ptype $char16_exp" "type = char16_t" \
"char16_t is distinct"
gdb_test "ptype $char32_exp" "type = char32_t" \
"char32_t is distinct"
} else {
gdb_test "ptype $char16_exp" "type = unsigned (long|int|short)" \
"char16_t is typedef"
gdb_test "ptype $char32_exp" "type = unsigned (long|int|short)" \
"char32_t is typedef"
}
Teach GDB that wchar_t is a built-in type in C++ mode GDB is currently not aware that wchar_t is a built-in type in C++ mode. This is usually not a problem because the debug info describes the type, so when you have a program loaded, you don't notice this. However, if you try expressions involving wchar_t before a program is loaded, gdb errors out: (gdb) p (wchar_t)-1 No symbol table is loaded. Use the "file" command. (gdb) p L"hello" No type named wchar_t. (gdb) ptype L"hello" No type named wchar_t. This commit teaches gdb about the type. After: (gdb) p (wchar_t)-1 $1 = -1 L'\xffffffff' (gdb) p L"hello" $2 = L"hello" (gdb) ptype L"hello" type = wchar_t [6] Unlike char16_t/char32_t, unfortunately, the underlying type of wchar_t is implementation dependent, both size and signness. So this requires adding a couple new gdbarch hooks. I grepped the GCC code base for WCHAR_TYPE and WCHAR_TYPE_SIZE, and it seems to me that the majority of the ABIs have a 4-byte signed wchar_t, so that's what I made the default for GDB too. And then I looked for which ports have a 16-bit and/or unsigned wchar_t, and made GDB follow suit. gdb/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR gdb/21323 * c-lang.c (cplus_primitive_types) <cplus_primitive_type_wchar_t>: New enum value. (cplus_language_arch_info): Register cplus_primitive_type_wchar_t. * gdbtypes.h (struct builtin_type) <builtin_wchar>: New field. * gdbtypes.c (gdbtypes_post_init): Create the "wchar_t" type. * gdbarch.sh (wchar_bit, wchar_signed): New per-arch values. * gdbarch.h, gdbarch.c: Regenerate. * aarch64-tdep.c (aarch64_gdbarch_init): Override gdbarch_wchar_bit and gdbarch_wchar_signed. * alpha-tdep.c (alpha_gdbarch_init): Likewise. * arm-tdep.c (arm_gdbarch_init): Likewise. * avr-tdep.c (avr_gdbarch_init): Likewise. * h8300-tdep.c (h8300_gdbarch_init): Likewise. * i386-nto-tdep.c (i386nto_init_abi): Likewise. * i386-tdep.c (i386_go32_init_abi): Likewise. * m32r-tdep.c (m32r_gdbarch_init): Likewise. * moxie-tdep.c (moxie_gdbarch_init): Likewise. * nds32-tdep.c (nds32_gdbarch_init): Likewise. * rs6000-aix-tdep.c (rs6000_aix_init_osabi): Likewise. * sh-tdep.c (sh_gdbarch_init): Likewise. * sparc-tdep.c (sparc32_gdbarch_init): Likewise. * sparc64-tdep.c (sparc64_init_abi): Likewise. * windows-tdep.c (windows_init_abi): Likewise. * xstormy16-tdep.c (xstormy16_gdbarch_init): Likewise. gdb/testsuite/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR gdb/21323 * gdb.cp/wide_char_types.c: Include <wchar.h>. (wchar): New global. * gdb.cp/wide_char_types.exp (wide_char_types_program) (do_test_wide_char, wide_char_types_no_program, top level): Add wchar_t testing.
2017-04-12 15:00:49 +02:00
# wchar_t is a disctinct built-in type in C++03+.
if {$lang != "c"} {
gdb_test "ptype $wchar_exp" "type = wchar_t" \
"wchar_t is distinct"
} else {
gdb_test "ptype $wchar_exp" "type = (unsigned )?(long|int|short)" \
"wchar_t is typedef"
}
Fix PR c++/21323: GDB thinks char16_t and char32_t are signed in C++ While the C++ standard says that char16_t and char32_t are unsigned types: Types char16_t and char32_t denote distinct types with the same size, signedness, and alignment as uint_least16_t and uint_least32_t, respectively, in <cstdint>, called the underlying types. ... gdb treats them as signed currently: (gdb) p (char16_t)-1 $1 = -1 u'\xffff' There are actually two places in gdb that hardcode these types: - gdbtypes.c:gdbtypes_post_init, when creating the built-in types, seemingly used by the "x /s" command (judging from commit 9a22f0d0). - dwarf2read.c, when reading base types with DW_ATE_UTF encoding (which is what is used for these types, when compiling for C++11 and up). Despite the comment, the type created does end up used. Both places need fixing. But since I couldn't tell why dwarf2read.c needs to create a new type, I've made it use the per-arch built-in types instead, so that the types are only created once per arch instead of once per objfile. That seems to work fine. While writting the test, I noticed that the C++ language parser isn't actually aware of these built-in types, so if you try to use them without a program that uses them, you get: (gdb) set language c++ (gdb) ptype char16_t No symbol table is loaded. Use the "file" command. (gdb) ptype u"hello" No type named char16_t. (gdb) p u"hello" No type named char16_t. That's fixed by simply adding a couple entries to C++'s built-in types array in c-lang.c. With that, we get the expected: (gdb) ptype char16_t type = char16_t (gdb) ptype u"hello" type = char16_t [6] (gdb) p u"hello" $1 = u"hello" gdb/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR c++/21323 * c-lang.c (cplus_primitive_types) <cplus_primitive_type_char16_t, cplus_primitive_type_char32_t>: New enum values. (cplus_language_arch_info): Register cplus_primitive_type_char16_t and cplus_primitive_type_char32_t. * dwarf2read.c (read_base_type) <DW_ATE_UTF>: If bit size is 16 or 32, use the archtecture's built-in type for char16_t and char32_t, respectively. Otherwise, fallback to init_integer_type as before, but make the type unsigned, and issue a complaint. * gdbtypes.c (gdbtypes_post_init): Make char16_t and char32_t unsigned. gdb/testsuite/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR c++/21323 * gdb.cp/wide_char_types.c: New file. * gdb.cp/wide_char_types.exp: New file.
2017-04-12 15:00:49 +02:00
# Check that the fixed-width wide char types are unsigned.
gdb_test "p $char16_exp" " = 65535 u'\\\\xffff'" \
"char16_t is unsigned"
gdb_test "p $char32_exp" " = 4294967295 U'\\\\xffffffff'" \
"char32_t is unsigned"
Teach GDB that wchar_t is a built-in type in C++ mode GDB is currently not aware that wchar_t is a built-in type in C++ mode. This is usually not a problem because the debug info describes the type, so when you have a program loaded, you don't notice this. However, if you try expressions involving wchar_t before a program is loaded, gdb errors out: (gdb) p (wchar_t)-1 No symbol table is loaded. Use the "file" command. (gdb) p L"hello" No type named wchar_t. (gdb) ptype L"hello" No type named wchar_t. This commit teaches gdb about the type. After: (gdb) p (wchar_t)-1 $1 = -1 L'\xffffffff' (gdb) p L"hello" $2 = L"hello" (gdb) ptype L"hello" type = wchar_t [6] Unlike char16_t/char32_t, unfortunately, the underlying type of wchar_t is implementation dependent, both size and signness. So this requires adding a couple new gdbarch hooks. I grepped the GCC code base for WCHAR_TYPE and WCHAR_TYPE_SIZE, and it seems to me that the majority of the ABIs have a 4-byte signed wchar_t, so that's what I made the default for GDB too. And then I looked for which ports have a 16-bit and/or unsigned wchar_t, and made GDB follow suit. gdb/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR gdb/21323 * c-lang.c (cplus_primitive_types) <cplus_primitive_type_wchar_t>: New enum value. (cplus_language_arch_info): Register cplus_primitive_type_wchar_t. * gdbtypes.h (struct builtin_type) <builtin_wchar>: New field. * gdbtypes.c (gdbtypes_post_init): Create the "wchar_t" type. * gdbarch.sh (wchar_bit, wchar_signed): New per-arch values. * gdbarch.h, gdbarch.c: Regenerate. * aarch64-tdep.c (aarch64_gdbarch_init): Override gdbarch_wchar_bit and gdbarch_wchar_signed. * alpha-tdep.c (alpha_gdbarch_init): Likewise. * arm-tdep.c (arm_gdbarch_init): Likewise. * avr-tdep.c (avr_gdbarch_init): Likewise. * h8300-tdep.c (h8300_gdbarch_init): Likewise. * i386-nto-tdep.c (i386nto_init_abi): Likewise. * i386-tdep.c (i386_go32_init_abi): Likewise. * m32r-tdep.c (m32r_gdbarch_init): Likewise. * moxie-tdep.c (moxie_gdbarch_init): Likewise. * nds32-tdep.c (nds32_gdbarch_init): Likewise. * rs6000-aix-tdep.c (rs6000_aix_init_osabi): Likewise. * sh-tdep.c (sh_gdbarch_init): Likewise. * sparc-tdep.c (sparc32_gdbarch_init): Likewise. * sparc64-tdep.c (sparc64_init_abi): Likewise. * windows-tdep.c (windows_init_abi): Likewise. * xstormy16-tdep.c (xstormy16_gdbarch_init): Likewise. gdb/testsuite/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR gdb/21323 * gdb.cp/wide_char_types.c: Include <wchar.h>. (wchar): New global. * gdb.cp/wide_char_types.exp (wide_char_types_program) (do_test_wide_char, wide_char_types_no_program, top level): Add wchar_t testing.
2017-04-12 15:00:49 +02:00
# Whether wchar_t is signed is implementation-dependent. While we
# ignore whether GDB got the ABI size/sign details right here,
# this at least verifies that the value isn't garbage, and that
# GDB correctly outputs the character using the "L" prefix.
set test "wchar_t sign"
gdb_test_multiple "p $wchar_exp" $test {
-re " = 4294967295 L'\\\\xffffffff'\r\n$gdb_prompt $" {
pass "$test (unsigned)"
}
-re " = 65535 L'\\\\xffff'\r\n$gdb_prompt $" {
pass "$test (unsigned)"
}
-re " = -1 L'\\\\xffffffff'\r\n$gdb_prompt $" {
pass "$test (signed)"
}
-re " = -1 L'\\\\xffff'\r\n$gdb_prompt $" {
pass "$test (signed)"
}
}
Fix PR c++/21323: GDB thinks char16_t and char32_t are signed in C++ While the C++ standard says that char16_t and char32_t are unsigned types: Types char16_t and char32_t denote distinct types with the same size, signedness, and alignment as uint_least16_t and uint_least32_t, respectively, in <cstdint>, called the underlying types. ... gdb treats them as signed currently: (gdb) p (char16_t)-1 $1 = -1 u'\xffff' There are actually two places in gdb that hardcode these types: - gdbtypes.c:gdbtypes_post_init, when creating the built-in types, seemingly used by the "x /s" command (judging from commit 9a22f0d0). - dwarf2read.c, when reading base types with DW_ATE_UTF encoding (which is what is used for these types, when compiling for C++11 and up). Despite the comment, the type created does end up used. Both places need fixing. But since I couldn't tell why dwarf2read.c needs to create a new type, I've made it use the per-arch built-in types instead, so that the types are only created once per arch instead of once per objfile. That seems to work fine. While writting the test, I noticed that the C++ language parser isn't actually aware of these built-in types, so if you try to use them without a program that uses them, you get: (gdb) set language c++ (gdb) ptype char16_t No symbol table is loaded. Use the "file" command. (gdb) ptype u"hello" No type named char16_t. (gdb) p u"hello" No type named char16_t. That's fixed by simply adding a couple entries to C++'s built-in types array in c-lang.c. With that, we get the expected: (gdb) ptype char16_t type = char16_t (gdb) ptype u"hello" type = char16_t [6] (gdb) p u"hello" $1 = u"hello" gdb/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR c++/21323 * c-lang.c (cplus_primitive_types) <cplus_primitive_type_char16_t, cplus_primitive_type_char32_t>: New enum values. (cplus_language_arch_info): Register cplus_primitive_type_char16_t and cplus_primitive_type_char32_t. * dwarf2read.c (read_base_type) <DW_ATE_UTF>: If bit size is 16 or 32, use the archtecture's built-in type for char16_t and char32_t, respectively. Otherwise, fallback to init_integer_type as before, but make the type unsigned, and issue a complaint. * gdbtypes.c (gdbtypes_post_init): Make char16_t and char32_t unsigned. gdb/testsuite/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR c++/21323 * gdb.cp/wide_char_types.c: New file. * gdb.cp/wide_char_types.exp: New file.
2017-04-12 15:00:49 +02:00
# Check sizeof. These are fixed-width.
gdb_test "p sizeof($char16_exp)" "= 2" \
"sizeof($char16_exp) == 2"
gdb_test "p sizeof($char32_exp)" "= 4" \
"sizeof(char16_t) == 4"
Teach GDB that wchar_t is a built-in type in C++ mode GDB is currently not aware that wchar_t is a built-in type in C++ mode. This is usually not a problem because the debug info describes the type, so when you have a program loaded, you don't notice this. However, if you try expressions involving wchar_t before a program is loaded, gdb errors out: (gdb) p (wchar_t)-1 No symbol table is loaded. Use the "file" command. (gdb) p L"hello" No type named wchar_t. (gdb) ptype L"hello" No type named wchar_t. This commit teaches gdb about the type. After: (gdb) p (wchar_t)-1 $1 = -1 L'\xffffffff' (gdb) p L"hello" $2 = L"hello" (gdb) ptype L"hello" type = wchar_t [6] Unlike char16_t/char32_t, unfortunately, the underlying type of wchar_t is implementation dependent, both size and signness. So this requires adding a couple new gdbarch hooks. I grepped the GCC code base for WCHAR_TYPE and WCHAR_TYPE_SIZE, and it seems to me that the majority of the ABIs have a 4-byte signed wchar_t, so that's what I made the default for GDB too. And then I looked for which ports have a 16-bit and/or unsigned wchar_t, and made GDB follow suit. gdb/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR gdb/21323 * c-lang.c (cplus_primitive_types) <cplus_primitive_type_wchar_t>: New enum value. (cplus_language_arch_info): Register cplus_primitive_type_wchar_t. * gdbtypes.h (struct builtin_type) <builtin_wchar>: New field. * gdbtypes.c (gdbtypes_post_init): Create the "wchar_t" type. * gdbarch.sh (wchar_bit, wchar_signed): New per-arch values. * gdbarch.h, gdbarch.c: Regenerate. * aarch64-tdep.c (aarch64_gdbarch_init): Override gdbarch_wchar_bit and gdbarch_wchar_signed. * alpha-tdep.c (alpha_gdbarch_init): Likewise. * arm-tdep.c (arm_gdbarch_init): Likewise. * avr-tdep.c (avr_gdbarch_init): Likewise. * h8300-tdep.c (h8300_gdbarch_init): Likewise. * i386-nto-tdep.c (i386nto_init_abi): Likewise. * i386-tdep.c (i386_go32_init_abi): Likewise. * m32r-tdep.c (m32r_gdbarch_init): Likewise. * moxie-tdep.c (moxie_gdbarch_init): Likewise. * nds32-tdep.c (nds32_gdbarch_init): Likewise. * rs6000-aix-tdep.c (rs6000_aix_init_osabi): Likewise. * sh-tdep.c (sh_gdbarch_init): Likewise. * sparc-tdep.c (sparc32_gdbarch_init): Likewise. * sparc64-tdep.c (sparc64_init_abi): Likewise. * windows-tdep.c (windows_init_abi): Likewise. * xstormy16-tdep.c (xstormy16_gdbarch_init): Likewise. gdb/testsuite/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR gdb/21323 * gdb.cp/wide_char_types.c: Include <wchar.h>. (wchar): New global. * gdb.cp/wide_char_types.exp (wide_char_types_program) (do_test_wide_char, wide_char_types_no_program, top level): Add wchar_t testing.
2017-04-12 15:00:49 +02:00
# Size of wchar_t depends on ABI.
gdb_test "p sizeof($wchar_exp)" "= (2|4)" \
"sizeof(wchar_t)"
Fix PR c++/21323: GDB thinks char16_t and char32_t are signed in C++ While the C++ standard says that char16_t and char32_t are unsigned types: Types char16_t and char32_t denote distinct types with the same size, signedness, and alignment as uint_least16_t and uint_least32_t, respectively, in <cstdint>, called the underlying types. ... gdb treats them as signed currently: (gdb) p (char16_t)-1 $1 = -1 u'\xffff' There are actually two places in gdb that hardcode these types: - gdbtypes.c:gdbtypes_post_init, when creating the built-in types, seemingly used by the "x /s" command (judging from commit 9a22f0d0). - dwarf2read.c, when reading base types with DW_ATE_UTF encoding (which is what is used for these types, when compiling for C++11 and up). Despite the comment, the type created does end up used. Both places need fixing. But since I couldn't tell why dwarf2read.c needs to create a new type, I've made it use the per-arch built-in types instead, so that the types are only created once per arch instead of once per objfile. That seems to work fine. While writting the test, I noticed that the C++ language parser isn't actually aware of these built-in types, so if you try to use them without a program that uses them, you get: (gdb) set language c++ (gdb) ptype char16_t No symbol table is loaded. Use the "file" command. (gdb) ptype u"hello" No type named char16_t. (gdb) p u"hello" No type named char16_t. That's fixed by simply adding a couple entries to C++'s built-in types array in c-lang.c. With that, we get the expected: (gdb) ptype char16_t type = char16_t (gdb) ptype u"hello" type = char16_t [6] (gdb) p u"hello" $1 = u"hello" gdb/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR c++/21323 * c-lang.c (cplus_primitive_types) <cplus_primitive_type_char16_t, cplus_primitive_type_char32_t>: New enum values. (cplus_language_arch_info): Register cplus_primitive_type_char16_t and cplus_primitive_type_char32_t. * dwarf2read.c (read_base_type) <DW_ATE_UTF>: If bit size is 16 or 32, use the archtecture's built-in type for char16_t and char32_t, respectively. Otherwise, fallback to init_integer_type as before, but make the type unsigned, and issue a complaint. * gdbtypes.c (gdbtypes_post_init): Make char16_t and char32_t unsigned. gdb/testsuite/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR c++/21323 * gdb.cp/wide_char_types.c: New file. * gdb.cp/wide_char_types.exp: New file.
2017-04-12 15:00:49 +02:00
# Test printing wide literal strings. Note that when testing with
# no program started, this relies on GDB's awareness of the
# built-in wide char types.
gdb_test {p U"hello"} {= U"hello"}
gdb_test {p u"hello"} {= u"hello"}
Teach GDB that wchar_t is a built-in type in C++ mode GDB is currently not aware that wchar_t is a built-in type in C++ mode. This is usually not a problem because the debug info describes the type, so when you have a program loaded, you don't notice this. However, if you try expressions involving wchar_t before a program is loaded, gdb errors out: (gdb) p (wchar_t)-1 No symbol table is loaded. Use the "file" command. (gdb) p L"hello" No type named wchar_t. (gdb) ptype L"hello" No type named wchar_t. This commit teaches gdb about the type. After: (gdb) p (wchar_t)-1 $1 = -1 L'\xffffffff' (gdb) p L"hello" $2 = L"hello" (gdb) ptype L"hello" type = wchar_t [6] Unlike char16_t/char32_t, unfortunately, the underlying type of wchar_t is implementation dependent, both size and signness. So this requires adding a couple new gdbarch hooks. I grepped the GCC code base for WCHAR_TYPE and WCHAR_TYPE_SIZE, and it seems to me that the majority of the ABIs have a 4-byte signed wchar_t, so that's what I made the default for GDB too. And then I looked for which ports have a 16-bit and/or unsigned wchar_t, and made GDB follow suit. gdb/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR gdb/21323 * c-lang.c (cplus_primitive_types) <cplus_primitive_type_wchar_t>: New enum value. (cplus_language_arch_info): Register cplus_primitive_type_wchar_t. * gdbtypes.h (struct builtin_type) <builtin_wchar>: New field. * gdbtypes.c (gdbtypes_post_init): Create the "wchar_t" type. * gdbarch.sh (wchar_bit, wchar_signed): New per-arch values. * gdbarch.h, gdbarch.c: Regenerate. * aarch64-tdep.c (aarch64_gdbarch_init): Override gdbarch_wchar_bit and gdbarch_wchar_signed. * alpha-tdep.c (alpha_gdbarch_init): Likewise. * arm-tdep.c (arm_gdbarch_init): Likewise. * avr-tdep.c (avr_gdbarch_init): Likewise. * h8300-tdep.c (h8300_gdbarch_init): Likewise. * i386-nto-tdep.c (i386nto_init_abi): Likewise. * i386-tdep.c (i386_go32_init_abi): Likewise. * m32r-tdep.c (m32r_gdbarch_init): Likewise. * moxie-tdep.c (moxie_gdbarch_init): Likewise. * nds32-tdep.c (nds32_gdbarch_init): Likewise. * rs6000-aix-tdep.c (rs6000_aix_init_osabi): Likewise. * sh-tdep.c (sh_gdbarch_init): Likewise. * sparc-tdep.c (sparc32_gdbarch_init): Likewise. * sparc64-tdep.c (sparc64_init_abi): Likewise. * windows-tdep.c (windows_init_abi): Likewise. * xstormy16-tdep.c (xstormy16_gdbarch_init): Likewise. gdb/testsuite/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR gdb/21323 * gdb.cp/wide_char_types.c: Include <wchar.h>. (wchar): New global. * gdb.cp/wide_char_types.exp (wide_char_types_program) (do_test_wide_char, wide_char_types_no_program, top level): Add wchar_t testing.
2017-04-12 15:00:49 +02:00
gdb_test {p L"hello"} {= L"hello"}
Fix PR c++/21323: GDB thinks char16_t and char32_t are signed in C++ While the C++ standard says that char16_t and char32_t are unsigned types: Types char16_t and char32_t denote distinct types with the same size, signedness, and alignment as uint_least16_t and uint_least32_t, respectively, in <cstdint>, called the underlying types. ... gdb treats them as signed currently: (gdb) p (char16_t)-1 $1 = -1 u'\xffff' There are actually two places in gdb that hardcode these types: - gdbtypes.c:gdbtypes_post_init, when creating the built-in types, seemingly used by the "x /s" command (judging from commit 9a22f0d0). - dwarf2read.c, when reading base types with DW_ATE_UTF encoding (which is what is used for these types, when compiling for C++11 and up). Despite the comment, the type created does end up used. Both places need fixing. But since I couldn't tell why dwarf2read.c needs to create a new type, I've made it use the per-arch built-in types instead, so that the types are only created once per arch instead of once per objfile. That seems to work fine. While writting the test, I noticed that the C++ language parser isn't actually aware of these built-in types, so if you try to use them without a program that uses them, you get: (gdb) set language c++ (gdb) ptype char16_t No symbol table is loaded. Use the "file" command. (gdb) ptype u"hello" No type named char16_t. (gdb) p u"hello" No type named char16_t. That's fixed by simply adding a couple entries to C++'s built-in types array in c-lang.c. With that, we get the expected: (gdb) ptype char16_t type = char16_t (gdb) ptype u"hello" type = char16_t [6] (gdb) p u"hello" $1 = u"hello" gdb/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR c++/21323 * c-lang.c (cplus_primitive_types) <cplus_primitive_type_char16_t, cplus_primitive_type_char32_t>: New enum values. (cplus_language_arch_info): Register cplus_primitive_type_char16_t and cplus_primitive_type_char32_t. * dwarf2read.c (read_base_type) <DW_ATE_UTF>: If bit size is 16 or 32, use the archtecture's built-in type for char16_t and char32_t, respectively. Otherwise, fallback to init_integer_type as before, but make the type unsigned, and issue a complaint. * gdbtypes.c (gdbtypes_post_init): Make char16_t and char32_t unsigned. gdb/testsuite/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR c++/21323 * gdb.cp/wide_char_types.c: New file. * gdb.cp/wide_char_types.exp: New file.
2017-04-12 15:00:49 +02:00
}
Teach GDB that wchar_t is a built-in type in C++ mode GDB is currently not aware that wchar_t is a built-in type in C++ mode. This is usually not a problem because the debug info describes the type, so when you have a program loaded, you don't notice this. However, if you try expressions involving wchar_t before a program is loaded, gdb errors out: (gdb) p (wchar_t)-1 No symbol table is loaded. Use the "file" command. (gdb) p L"hello" No type named wchar_t. (gdb) ptype L"hello" No type named wchar_t. This commit teaches gdb about the type. After: (gdb) p (wchar_t)-1 $1 = -1 L'\xffffffff' (gdb) p L"hello" $2 = L"hello" (gdb) ptype L"hello" type = wchar_t [6] Unlike char16_t/char32_t, unfortunately, the underlying type of wchar_t is implementation dependent, both size and signness. So this requires adding a couple new gdbarch hooks. I grepped the GCC code base for WCHAR_TYPE and WCHAR_TYPE_SIZE, and it seems to me that the majority of the ABIs have a 4-byte signed wchar_t, so that's what I made the default for GDB too. And then I looked for which ports have a 16-bit and/or unsigned wchar_t, and made GDB follow suit. gdb/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR gdb/21323 * c-lang.c (cplus_primitive_types) <cplus_primitive_type_wchar_t>: New enum value. (cplus_language_arch_info): Register cplus_primitive_type_wchar_t. * gdbtypes.h (struct builtin_type) <builtin_wchar>: New field. * gdbtypes.c (gdbtypes_post_init): Create the "wchar_t" type. * gdbarch.sh (wchar_bit, wchar_signed): New per-arch values. * gdbarch.h, gdbarch.c: Regenerate. * aarch64-tdep.c (aarch64_gdbarch_init): Override gdbarch_wchar_bit and gdbarch_wchar_signed. * alpha-tdep.c (alpha_gdbarch_init): Likewise. * arm-tdep.c (arm_gdbarch_init): Likewise. * avr-tdep.c (avr_gdbarch_init): Likewise. * h8300-tdep.c (h8300_gdbarch_init): Likewise. * i386-nto-tdep.c (i386nto_init_abi): Likewise. * i386-tdep.c (i386_go32_init_abi): Likewise. * m32r-tdep.c (m32r_gdbarch_init): Likewise. * moxie-tdep.c (moxie_gdbarch_init): Likewise. * nds32-tdep.c (nds32_gdbarch_init): Likewise. * rs6000-aix-tdep.c (rs6000_aix_init_osabi): Likewise. * sh-tdep.c (sh_gdbarch_init): Likewise. * sparc-tdep.c (sparc32_gdbarch_init): Likewise. * sparc64-tdep.c (sparc64_init_abi): Likewise. * windows-tdep.c (windows_init_abi): Likewise. * xstormy16-tdep.c (xstormy16_gdbarch_init): Likewise. gdb/testsuite/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR gdb/21323 * gdb.cp/wide_char_types.c: Include <wchar.h>. (wchar): New global. * gdb.cp/wide_char_types.exp (wide_char_types_program) (do_test_wide_char, wide_char_types_no_program, top level): Add wchar_t testing.
2017-04-12 15:00:49 +02:00
# Make sure that the char16_t/char32_t/wchar_t types are recognized as
Fix PR c++/21323: GDB thinks char16_t and char32_t are signed in C++ While the C++ standard says that char16_t and char32_t are unsigned types: Types char16_t and char32_t denote distinct types with the same size, signedness, and alignment as uint_least16_t and uint_least32_t, respectively, in <cstdint>, called the underlying types. ... gdb treats them as signed currently: (gdb) p (char16_t)-1 $1 = -1 u'\xffff' There are actually two places in gdb that hardcode these types: - gdbtypes.c:gdbtypes_post_init, when creating the built-in types, seemingly used by the "x /s" command (judging from commit 9a22f0d0). - dwarf2read.c, when reading base types with DW_ATE_UTF encoding (which is what is used for these types, when compiling for C++11 and up). Despite the comment, the type created does end up used. Both places need fixing. But since I couldn't tell why dwarf2read.c needs to create a new type, I've made it use the per-arch built-in types instead, so that the types are only created once per arch instead of once per objfile. That seems to work fine. While writting the test, I noticed that the C++ language parser isn't actually aware of these built-in types, so if you try to use them without a program that uses them, you get: (gdb) set language c++ (gdb) ptype char16_t No symbol table is loaded. Use the "file" command. (gdb) ptype u"hello" No type named char16_t. (gdb) p u"hello" No type named char16_t. That's fixed by simply adding a couple entries to C++'s built-in types array in c-lang.c. With that, we get the expected: (gdb) ptype char16_t type = char16_t (gdb) ptype u"hello" type = char16_t [6] (gdb) p u"hello" $1 = u"hello" gdb/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR c++/21323 * c-lang.c (cplus_primitive_types) <cplus_primitive_type_char16_t, cplus_primitive_type_char32_t>: New enum values. (cplus_language_arch_info): Register cplus_primitive_type_char16_t and cplus_primitive_type_char32_t. * dwarf2read.c (read_base_type) <DW_ATE_UTF>: If bit size is 16 or 32, use the archtecture's built-in type for char16_t and char32_t, respectively. Otherwise, fallback to init_integer_type as before, but make the type unsigned, and issue a complaint. * gdbtypes.c (gdbtypes_post_init): Make char16_t and char32_t unsigned. gdb/testsuite/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR c++/21323 * gdb.cp/wide_char_types.c: New file. * gdb.cp/wide_char_types.exp: New file.
2017-04-12 15:00:49 +02:00
# distinct built-in types in C++ mode, even with no program loaded.
# Check that in C mode, the types are not recognized.
proc wide_char_types_no_program {} {
global srcfile testfile
gdb_exit
gdb_start
# These types are not built-in in C.
with_test_prefix "c" {
gdb_test "set language c"
gdb_test "p (char16_t) -1" "No symbol table is loaded.*" \
"char16_t is not built-in"
gdb_test "p (char32_t) -1" "No symbol table is loaded.*" \
"char32_t is not built-in"
Teach GDB that wchar_t is a built-in type in C++ mode GDB is currently not aware that wchar_t is a built-in type in C++ mode. This is usually not a problem because the debug info describes the type, so when you have a program loaded, you don't notice this. However, if you try expressions involving wchar_t before a program is loaded, gdb errors out: (gdb) p (wchar_t)-1 No symbol table is loaded. Use the "file" command. (gdb) p L"hello" No type named wchar_t. (gdb) ptype L"hello" No type named wchar_t. This commit teaches gdb about the type. After: (gdb) p (wchar_t)-1 $1 = -1 L'\xffffffff' (gdb) p L"hello" $2 = L"hello" (gdb) ptype L"hello" type = wchar_t [6] Unlike char16_t/char32_t, unfortunately, the underlying type of wchar_t is implementation dependent, both size and signness. So this requires adding a couple new gdbarch hooks. I grepped the GCC code base for WCHAR_TYPE and WCHAR_TYPE_SIZE, and it seems to me that the majority of the ABIs have a 4-byte signed wchar_t, so that's what I made the default for GDB too. And then I looked for which ports have a 16-bit and/or unsigned wchar_t, and made GDB follow suit. gdb/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR gdb/21323 * c-lang.c (cplus_primitive_types) <cplus_primitive_type_wchar_t>: New enum value. (cplus_language_arch_info): Register cplus_primitive_type_wchar_t. * gdbtypes.h (struct builtin_type) <builtin_wchar>: New field. * gdbtypes.c (gdbtypes_post_init): Create the "wchar_t" type. * gdbarch.sh (wchar_bit, wchar_signed): New per-arch values. * gdbarch.h, gdbarch.c: Regenerate. * aarch64-tdep.c (aarch64_gdbarch_init): Override gdbarch_wchar_bit and gdbarch_wchar_signed. * alpha-tdep.c (alpha_gdbarch_init): Likewise. * arm-tdep.c (arm_gdbarch_init): Likewise. * avr-tdep.c (avr_gdbarch_init): Likewise. * h8300-tdep.c (h8300_gdbarch_init): Likewise. * i386-nto-tdep.c (i386nto_init_abi): Likewise. * i386-tdep.c (i386_go32_init_abi): Likewise. * m32r-tdep.c (m32r_gdbarch_init): Likewise. * moxie-tdep.c (moxie_gdbarch_init): Likewise. * nds32-tdep.c (nds32_gdbarch_init): Likewise. * rs6000-aix-tdep.c (rs6000_aix_init_osabi): Likewise. * sh-tdep.c (sh_gdbarch_init): Likewise. * sparc-tdep.c (sparc32_gdbarch_init): Likewise. * sparc64-tdep.c (sparc64_init_abi): Likewise. * windows-tdep.c (windows_init_abi): Likewise. * xstormy16-tdep.c (xstormy16_gdbarch_init): Likewise. gdb/testsuite/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR gdb/21323 * gdb.cp/wide_char_types.c: Include <wchar.h>. (wchar): New global. * gdb.cp/wide_char_types.exp (wide_char_types_program) (do_test_wide_char, wide_char_types_no_program, top level): Add wchar_t testing.
2017-04-12 15:00:49 +02:00
gdb_test "p (wchar_t) -1" "No symbol table is loaded.*" \
"wchar_t is not built-in"
Fix PR c++/21323: GDB thinks char16_t and char32_t are signed in C++ While the C++ standard says that char16_t and char32_t are unsigned types: Types char16_t and char32_t denote distinct types with the same size, signedness, and alignment as uint_least16_t and uint_least32_t, respectively, in <cstdint>, called the underlying types. ... gdb treats them as signed currently: (gdb) p (char16_t)-1 $1 = -1 u'\xffff' There are actually two places in gdb that hardcode these types: - gdbtypes.c:gdbtypes_post_init, when creating the built-in types, seemingly used by the "x /s" command (judging from commit 9a22f0d0). - dwarf2read.c, when reading base types with DW_ATE_UTF encoding (which is what is used for these types, when compiling for C++11 and up). Despite the comment, the type created does end up used. Both places need fixing. But since I couldn't tell why dwarf2read.c needs to create a new type, I've made it use the per-arch built-in types instead, so that the types are only created once per arch instead of once per objfile. That seems to work fine. While writting the test, I noticed that the C++ language parser isn't actually aware of these built-in types, so if you try to use them without a program that uses them, you get: (gdb) set language c++ (gdb) ptype char16_t No symbol table is loaded. Use the "file" command. (gdb) ptype u"hello" No type named char16_t. (gdb) p u"hello" No type named char16_t. That's fixed by simply adding a couple entries to C++'s built-in types array in c-lang.c. With that, we get the expected: (gdb) ptype char16_t type = char16_t (gdb) ptype u"hello" type = char16_t [6] (gdb) p u"hello" $1 = u"hello" gdb/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR c++/21323 * c-lang.c (cplus_primitive_types) <cplus_primitive_type_char16_t, cplus_primitive_type_char32_t>: New enum values. (cplus_language_arch_info): Register cplus_primitive_type_char16_t and cplus_primitive_type_char32_t. * dwarf2read.c (read_base_type) <DW_ATE_UTF>: If bit size is 16 or 32, use the archtecture's built-in type for char16_t and char32_t, respectively. Otherwise, fallback to init_integer_type as before, but make the type unsigned, and issue a complaint. * gdbtypes.c (gdbtypes_post_init): Make char16_t and char32_t unsigned. gdb/testsuite/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR c++/21323 * gdb.cp/wide_char_types.c: New file. * gdb.cp/wide_char_types.exp: New file.
2017-04-12 15:00:49 +02:00
gdb_test {p U"hello"} "No type named char32_t\\\."
gdb_test {p u"hello"} "No type named char16_t\\\."
Teach GDB that wchar_t is a built-in type in C++ mode GDB is currently not aware that wchar_t is a built-in type in C++ mode. This is usually not a problem because the debug info describes the type, so when you have a program loaded, you don't notice this. However, if you try expressions involving wchar_t before a program is loaded, gdb errors out: (gdb) p (wchar_t)-1 No symbol table is loaded. Use the "file" command. (gdb) p L"hello" No type named wchar_t. (gdb) ptype L"hello" No type named wchar_t. This commit teaches gdb about the type. After: (gdb) p (wchar_t)-1 $1 = -1 L'\xffffffff' (gdb) p L"hello" $2 = L"hello" (gdb) ptype L"hello" type = wchar_t [6] Unlike char16_t/char32_t, unfortunately, the underlying type of wchar_t is implementation dependent, both size and signness. So this requires adding a couple new gdbarch hooks. I grepped the GCC code base for WCHAR_TYPE and WCHAR_TYPE_SIZE, and it seems to me that the majority of the ABIs have a 4-byte signed wchar_t, so that's what I made the default for GDB too. And then I looked for which ports have a 16-bit and/or unsigned wchar_t, and made GDB follow suit. gdb/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR gdb/21323 * c-lang.c (cplus_primitive_types) <cplus_primitive_type_wchar_t>: New enum value. (cplus_language_arch_info): Register cplus_primitive_type_wchar_t. * gdbtypes.h (struct builtin_type) <builtin_wchar>: New field. * gdbtypes.c (gdbtypes_post_init): Create the "wchar_t" type. * gdbarch.sh (wchar_bit, wchar_signed): New per-arch values. * gdbarch.h, gdbarch.c: Regenerate. * aarch64-tdep.c (aarch64_gdbarch_init): Override gdbarch_wchar_bit and gdbarch_wchar_signed. * alpha-tdep.c (alpha_gdbarch_init): Likewise. * arm-tdep.c (arm_gdbarch_init): Likewise. * avr-tdep.c (avr_gdbarch_init): Likewise. * h8300-tdep.c (h8300_gdbarch_init): Likewise. * i386-nto-tdep.c (i386nto_init_abi): Likewise. * i386-tdep.c (i386_go32_init_abi): Likewise. * m32r-tdep.c (m32r_gdbarch_init): Likewise. * moxie-tdep.c (moxie_gdbarch_init): Likewise. * nds32-tdep.c (nds32_gdbarch_init): Likewise. * rs6000-aix-tdep.c (rs6000_aix_init_osabi): Likewise. * sh-tdep.c (sh_gdbarch_init): Likewise. * sparc-tdep.c (sparc32_gdbarch_init): Likewise. * sparc64-tdep.c (sparc64_init_abi): Likewise. * windows-tdep.c (windows_init_abi): Likewise. * xstormy16-tdep.c (xstormy16_gdbarch_init): Likewise. gdb/testsuite/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR gdb/21323 * gdb.cp/wide_char_types.c: Include <wchar.h>. (wchar): New global. * gdb.cp/wide_char_types.exp (wide_char_types_program) (do_test_wide_char, wide_char_types_no_program, top level): Add wchar_t testing.
2017-04-12 15:00:49 +02:00
gdb_test {p L"hello"} "No type named wchar_t\\\."
Fix PR c++/21323: GDB thinks char16_t and char32_t are signed in C++ While the C++ standard says that char16_t and char32_t are unsigned types: Types char16_t and char32_t denote distinct types with the same size, signedness, and alignment as uint_least16_t and uint_least32_t, respectively, in <cstdint>, called the underlying types. ... gdb treats them as signed currently: (gdb) p (char16_t)-1 $1 = -1 u'\xffff' There are actually two places in gdb that hardcode these types: - gdbtypes.c:gdbtypes_post_init, when creating the built-in types, seemingly used by the "x /s" command (judging from commit 9a22f0d0). - dwarf2read.c, when reading base types with DW_ATE_UTF encoding (which is what is used for these types, when compiling for C++11 and up). Despite the comment, the type created does end up used. Both places need fixing. But since I couldn't tell why dwarf2read.c needs to create a new type, I've made it use the per-arch built-in types instead, so that the types are only created once per arch instead of once per objfile. That seems to work fine. While writting the test, I noticed that the C++ language parser isn't actually aware of these built-in types, so if you try to use them without a program that uses them, you get: (gdb) set language c++ (gdb) ptype char16_t No symbol table is loaded. Use the "file" command. (gdb) ptype u"hello" No type named char16_t. (gdb) p u"hello" No type named char16_t. That's fixed by simply adding a couple entries to C++'s built-in types array in c-lang.c. With that, we get the expected: (gdb) ptype char16_t type = char16_t (gdb) ptype u"hello" type = char16_t [6] (gdb) p u"hello" $1 = u"hello" gdb/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR c++/21323 * c-lang.c (cplus_primitive_types) <cplus_primitive_type_char16_t, cplus_primitive_type_char32_t>: New enum values. (cplus_language_arch_info): Register cplus_primitive_type_char16_t and cplus_primitive_type_char32_t. * dwarf2read.c (read_base_type) <DW_ATE_UTF>: If bit size is 16 or 32, use the archtecture's built-in type for char16_t and char32_t, respectively. Otherwise, fallback to init_integer_type as before, but make the type unsigned, and issue a complaint. * gdbtypes.c (gdbtypes_post_init): Make char16_t and char32_t unsigned. gdb/testsuite/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR c++/21323 * gdb.cp/wide_char_types.c: New file. * gdb.cp/wide_char_types.exp: New file.
2017-04-12 15:00:49 +02:00
}
# Note GDB does not distinguish C++ dialects, so the fixed-width
# types are always available in C++ mode, even if they were not
# built-in types before C++11.
with_test_prefix "c++" {
gdb_test "set language c++"
Teach GDB that wchar_t is a built-in type in C++ mode GDB is currently not aware that wchar_t is a built-in type in C++ mode. This is usually not a problem because the debug info describes the type, so when you have a program loaded, you don't notice this. However, if you try expressions involving wchar_t before a program is loaded, gdb errors out: (gdb) p (wchar_t)-1 No symbol table is loaded. Use the "file" command. (gdb) p L"hello" No type named wchar_t. (gdb) ptype L"hello" No type named wchar_t. This commit teaches gdb about the type. After: (gdb) p (wchar_t)-1 $1 = -1 L'\xffffffff' (gdb) p L"hello" $2 = L"hello" (gdb) ptype L"hello" type = wchar_t [6] Unlike char16_t/char32_t, unfortunately, the underlying type of wchar_t is implementation dependent, both size and signness. So this requires adding a couple new gdbarch hooks. I grepped the GCC code base for WCHAR_TYPE and WCHAR_TYPE_SIZE, and it seems to me that the majority of the ABIs have a 4-byte signed wchar_t, so that's what I made the default for GDB too. And then I looked for which ports have a 16-bit and/or unsigned wchar_t, and made GDB follow suit. gdb/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR gdb/21323 * c-lang.c (cplus_primitive_types) <cplus_primitive_type_wchar_t>: New enum value. (cplus_language_arch_info): Register cplus_primitive_type_wchar_t. * gdbtypes.h (struct builtin_type) <builtin_wchar>: New field. * gdbtypes.c (gdbtypes_post_init): Create the "wchar_t" type. * gdbarch.sh (wchar_bit, wchar_signed): New per-arch values. * gdbarch.h, gdbarch.c: Regenerate. * aarch64-tdep.c (aarch64_gdbarch_init): Override gdbarch_wchar_bit and gdbarch_wchar_signed. * alpha-tdep.c (alpha_gdbarch_init): Likewise. * arm-tdep.c (arm_gdbarch_init): Likewise. * avr-tdep.c (avr_gdbarch_init): Likewise. * h8300-tdep.c (h8300_gdbarch_init): Likewise. * i386-nto-tdep.c (i386nto_init_abi): Likewise. * i386-tdep.c (i386_go32_init_abi): Likewise. * m32r-tdep.c (m32r_gdbarch_init): Likewise. * moxie-tdep.c (moxie_gdbarch_init): Likewise. * nds32-tdep.c (nds32_gdbarch_init): Likewise. * rs6000-aix-tdep.c (rs6000_aix_init_osabi): Likewise. * sh-tdep.c (sh_gdbarch_init): Likewise. * sparc-tdep.c (sparc32_gdbarch_init): Likewise. * sparc64-tdep.c (sparc64_init_abi): Likewise. * windows-tdep.c (windows_init_abi): Likewise. * xstormy16-tdep.c (xstormy16_gdbarch_init): Likewise. gdb/testsuite/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR gdb/21323 * gdb.cp/wide_char_types.c: Include <wchar.h>. (wchar): New global. * gdb.cp/wide_char_types.exp (wide_char_types_program) (do_test_wide_char, wide_char_types_no_program, top level): Add wchar_t testing.
2017-04-12 15:00:49 +02:00
do_test_wide_char "c++11" "(char16_t) -1" "(char32_t) -1" "(wchar_t) -1"
Fix PR c++/21323: GDB thinks char16_t and char32_t are signed in C++ While the C++ standard says that char16_t and char32_t are unsigned types: Types char16_t and char32_t denote distinct types with the same size, signedness, and alignment as uint_least16_t and uint_least32_t, respectively, in <cstdint>, called the underlying types. ... gdb treats them as signed currently: (gdb) p (char16_t)-1 $1 = -1 u'\xffff' There are actually two places in gdb that hardcode these types: - gdbtypes.c:gdbtypes_post_init, when creating the built-in types, seemingly used by the "x /s" command (judging from commit 9a22f0d0). - dwarf2read.c, when reading base types with DW_ATE_UTF encoding (which is what is used for these types, when compiling for C++11 and up). Despite the comment, the type created does end up used. Both places need fixing. But since I couldn't tell why dwarf2read.c needs to create a new type, I've made it use the per-arch built-in types instead, so that the types are only created once per arch instead of once per objfile. That seems to work fine. While writting the test, I noticed that the C++ language parser isn't actually aware of these built-in types, so if you try to use them without a program that uses them, you get: (gdb) set language c++ (gdb) ptype char16_t No symbol table is loaded. Use the "file" command. (gdb) ptype u"hello" No type named char16_t. (gdb) p u"hello" No type named char16_t. That's fixed by simply adding a couple entries to C++'s built-in types array in c-lang.c. With that, we get the expected: (gdb) ptype char16_t type = char16_t (gdb) ptype u"hello" type = char16_t [6] (gdb) p u"hello" $1 = u"hello" gdb/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR c++/21323 * c-lang.c (cplus_primitive_types) <cplus_primitive_type_char16_t, cplus_primitive_type_char32_t>: New enum values. (cplus_language_arch_info): Register cplus_primitive_type_char16_t and cplus_primitive_type_char32_t. * dwarf2read.c (read_base_type) <DW_ATE_UTF>: If bit size is 16 or 32, use the archtecture's built-in type for char16_t and char32_t, respectively. Otherwise, fallback to init_integer_type as before, but make the type unsigned, and issue a complaint. * gdbtypes.c (gdbtypes_post_init): Make char16_t and char32_t unsigned. gdb/testsuite/ChangeLog: 2017-04-12 Pedro Alves <palves@redhat.com> PR c++/21323 * gdb.cp/wide_char_types.c: New file. * gdb.cp/wide_char_types.exp: New file.
2017-04-12 15:00:49 +02:00
}
}
# Check wide char types with no program loaded.
with_test_prefix "no program" {
wide_char_types_no_program
}
# Check types when a program is loaded.
with_test_prefix "with program" {
foreach_with_prefix lang {"c" "c++03" "c++11"} {
wide_char_types_program $lang
}
}