When compiling gdb with '-lasan -fsanitizer=address' and running tests with:
- export ASAN_OPTIONS="detect_leaks=0:alloc_dealloc_mismatch=0",
- target board cc-with-gdb-index,
- the "[gdb/testsuite] Fix gdb.base/break-probes.exp with native-gdbserver"
commit reverted to avoid running into PR24617,
we get with gdb.arch/amd64-init-x87-values.exp:
...
==31229==ERROR: AddressSanitizer: heap-buffer-overflow on address \
0x62500098c93c at pc 0x000000bcc748 bp 0x7ffe39487660 sp 0x7ffe39487658
READ of size 1 at 0x62500098c93c thread T0
#0 0xbcc747 in cp_find_first_component_aux src/gdb/cp-support.c:999
#1 0xbcc6e9 in cp_find_first_component(char const*) \
src/gdb/cp-support.c:977
#2 0xcc2cf3 in mapped_index_base::build_name_components() \
src/gdb/dwarf2read.c:4499
#3 0xcc3322 in dw2_expand_symtabs_matching_symbol src/gdb/dwarf2read.c:4552
#4 0xcc817f in dw2_expand_symtabs_matching src/gdb/dwarf2read.c:5228
#5 0xfe8f48 in iterate_over_all_matching_symtabs src/gdb/linespec.c:1147
#6 0x1003506 in add_matching_symbols_to_info src/gdb/linespec.c:4413
#7 0xffe21b in find_function_symbols src/gdb/linespec.c:3886
#8 0xffe4a2 in find_linespec_symbols src/gdb/linespec.c:3914
#9 0xfee3ad in linespec_parse_basic src/gdb/linespec.c:1865
#10 0xff5128 in parse_linespec src/gdb/linespec.c:2655
#11 0xff8872 in event_location_to_sals src/gdb/linespec.c:3150
#12 0xff90a8 in decode_line_full(event_location const*, int, \
program_space*, symtab*, int, linespec_result*, \
char const*, char const*) src/gdb/linespec.c:3230
#13 0x9ce449 in parse_breakpoint_sals src/gdb/breakpoint.c:9057
#14 0x9ea022 in create_sals_from_location_default src/gdb/breakpoint.c:13708
#15 0x9e2c1f in bkpt_create_sals_from_location src/gdb/breakpoint.c:12514
#16 0x9cff06 in create_breakpoint(gdbarch*, event_location const*, \
char const*, int, char const*, int, int, bptype, int, \
auto_boolean, breakpoint_ops const*, int, int, int, \
unsigned int) src/gdb/breakpoint.c:9238
#17 0x9d114a in break_command_1 src/gdb/breakpoint.c:9402
#18 0x9d1b60 in break_command(char const*, int) src/gdb/breakpoint.c:9473
#19 0xac96aa in do_const_cfunc src/gdb/cli/cli-decode.c:106
#20 0xad0e5a in cmd_func(cmd_list_element*, char const*, int) \
src/gdb/cli/cli-decode.c:1892
#21 0x15226f6 in execute_command(char const*, int) src/gdb/top.c:630
#22 0xddde37 in command_handler(char const*) src/gdb/event-top.c:586
#23 0xdde7c1 in command_line_handler(std::unique_ptr<char, \
gdb::xfree_deleter<char> >&&) src/gdb/event-top.c:773
#24 0xddc9e8 in gdb_rl_callback_handler src/gdb/event-top.c:217
#25 0x16f2198 in rl_callback_read_char src/readline/callback.c:220
#26 0xddc5a1 in gdb_rl_callback_read_char_wrapper_noexcept \
src/gdb/event-top.c:175
#27 0xddc773 in gdb_rl_callback_read_char_wrapper src/gdb/event-top.c:192
#28 0xddd9f5 in stdin_event_handler(int, void*) src/gdb/event-top.c:514
#29 0xdd7d8f in handle_file_event src/gdb/event-loop.c:731
#30 0xdd8607 in gdb_wait_for_event src/gdb/event-loop.c:857
#31 0xdd629c in gdb_do_one_event() src/gdb/event-loop.c:321
#32 0xdd6344 in start_event_loop() src/gdb/event-loop.c:370
#33 0x10a7715 in captured_command_loop src/gdb/main.c:331
#34 0x10aa548 in captured_main src/gdb/main.c:1173
#35 0x10aa5d8 in gdb_main(captured_main_args*) src/gdb/main.c:1188
#36 0x87bd35 in main src/gdb/gdb.c:32
#37 0x7f16e1434f89 in __libc_start_main (/lib64/libc.so.6+0x20f89)
#38 0x87bb49 in _start (build/gdb/gdb+0x87bb49)
0x62500098c93c is located 0 bytes to the right of 8252-byte region \
[0x62500098a900,0x62500098c93c)
allocated by thread T0 here:
#0 0x7f16e359a600 in malloc (/usr/lib64/libasan.so.5+0xeb600)
#1 0x1742ddf in bfd_malloc src/bfd/libbfd.c:275
#2 0x1738824 in bfd_get_full_section_contents src/bfd/compress.c:253
#3 0xe30044 in gdb_bfd_map_section(bfd_section*, unsigned long*) \
src/gdb/gdb_bfd.c:704
#4 0xcb56bf in dwarf2_read_section(objfile*, dwarf2_section_info*) \
src/gdb/dwarf2read.c:2539
#5 0xd5bcd0 in get_gdb_index_contents_from_section<dwarf2_per_objfile> \
src/gdb/dwarf2read.c:6217
#6 0xd7fc7d in gdb::function_view<gdb::array_view<unsigned char const> \
(...) const src/gdb/common/function-view.h:284
#7 0xd7fddd in gdb::function_view<gdb::array_view<unsigned char const> \
(...) src/gdb/common/function-view.h:278
#8 0xd730cf in gdb::function_view<gdb::array_view<unsigned char const> \
(...) const src/gdb/common/function-view.h:247
#9 0xcbc7ee in dwarf2_read_gdb_index src/gdb/dwarf2read.c:3582
#10 0xcce731 in dwarf2_initialize_objfile(objfile*, dw_index_kind*) \
src/gdb/dwarf2read.c:6297
#11 0xdb88c4 in elf_symfile_read src/gdb/elfread.c:1256
#12 0x141262a in read_symbols src/gdb/symfile.c:798
#13 0x14140a7 in syms_from_objfile_1 src/gdb/symfile.c:1000
#14 0x1414393 in syms_from_objfile src/gdb/symfile.c:1017
#15 0x1414fb7 in symbol_file_add_with_addrs src/gdb/symfile.c:1124
#16 0x14159b7 in symbol_file_add_from_bfd(bfd*, char const*, \
enum_flags<symfile_add_flag>, std::vector<other_sections, \
std::allocator<other_sections> >*, \
enum_flags<objfile_flag>, objfile*) src/gdb/symfile.c:1203
#17 0x1415b6c in symbol_file_add(char const*,
enum_flags<symfile_add_flag>, std::vector<other_sections, \
std::allocator<other_sections> >*, \
enum_flags<objfile_flag>) src/gdb/symfile.c:1216
#18 0x1415f2f in symbol_file_add_main_1 src/gdb/symfile.c:1240
#19 0x1418599 in symbol_file_command(char const*, int) \
src/gdb/symfile.c:1675
#20 0xde2fa6 in file_command src/gdb/exec.c:433
#21 0xac96aa in do_const_cfunc src/gdb/cli/cli-decode.c:106
#22 0xad0e5a in cmd_func(cmd_list_element*, char const*, int) \
src/gdb/cli/cli-decode.c:1892
#23 0x15226f6 in execute_command(char const*, int) src/gdb/top.c:630
#24 0xddde37 in command_handler(char const*) src/gdb/event-top.c:586
#25 0xdde7c1 in command_line_handler(std::unique_ptr<char, \
gdb::xfree_deleter<char> >&&) src/gdb/event-top.c:773
#26 0xddc9e8 in gdb_rl_callback_handler src/gdb/event-top.c:217
#27 0x16f2198 in rl_callback_read_char src/readline/callback.c:220
#28 0xddc5a1 in gdb_rl_callback_read_char_wrapper_noexcept \
src/gdb/event-top.c:175
#29 0xddc773 in gdb_rl_callback_read_char_wrapper src/gdb/event-top.c:192
SUMMARY: AddressSanitizer: heap-buffer-overflow src/gdb/cp-support.c:999 in \
cp_find_first_component_aux
Shadow bytes around the buggy address:
0x0c4a801298d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c4a801298e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c4a801298f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c4a80129900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c4a80129910: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c4a80129920: 00 00 00 00 00 00 00[04]fa fa fa fa fa fa fa fa
0x0c4a80129930: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c4a80129940: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c4a80129950: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c4a80129960: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c4a80129970: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==31229==ABORTING
...
The problem happens as follows.
The executable amd64-init-x87-values gets an index (due to target board
cc-with-gdb-index), which looks as follows:
...
Hex dump of section '.gdb_index':
0x00000000 08000000 18000000 28000000 28000000 ........(...(...
0x00000010 3c000000 3c200000 00000000 00000000 <...< ..........
0x00000020 2e000000 00000000 d4004000 00000000 ..........@.....
0x00000030 db004000 00000000 00000000 00000000 ..@.............
0x00000040 00000000 00000000 00000000 00000000 ................
0x00000050 00000000 00000000 00000000 00000000 ................
... more zeroes ...
0x00002010 00000000 00000000 00000000 00000000 ................
0x00002020 00000000 00000000 00000000 00000000 ................
0x00002030 00000000 00000000 00000000 ............
...
The structure of this index is:
...
header : [0x0, 0x18) : size 0x18
culist : [0x18 ,0x28) : size 0x10
typesculist : [0x28, 0x28) : size 0x0
adress area : [0x28, 0x3c) : size 0x14
symbol table : [0x3c, 0x203c) : size 0x2000
constant pool: [0x203c, 0x203c): size 0x0
EOF : 0x203c
...
Note that the symbol table consists entirely of empty slots (where an empty
slot is a pair of 32-bit zeroes), and that the constant pool is empty.
The problem happens here in mapped_index_base::build_name_components:
...
auto count = this->symbol_name_count ();
for (offset_type idx = 0; idx < count; idx++)
{
if (this->symbol_name_slot_invalid (idx))
continue;
const char *name = this->symbol_name_at (idx);
...
when accessing the slot at idx == 0 in the symbol table,
symbol_name_slot_invalid returns false so we calculate name, which is
calculated using 'constant_pool + symbol_table[idx].name', which means we get
name == constant_pool. And given that the constant pool is empty, name now
points past the memory allocated for the index, and when we access name[0] for
the first time in cp_find_first_component_aux, we run into the
heap-buffer-overflow.
Fix this by fixing the definition of symbol_name_slot_invalid:
...
- return bucket.name == 0 && bucket.vec;
+ return bucket.name == 0 && bucket.vec == 0;
...
Tested on x86_64-linux.
gdb/ChangeLog:
2019-06-10 Tom de Vries <tdevries@suse.de>
PR gdb/24618
* dwarf2read.c (struct mapped_index::symbol_name_slot_invalid): Make
sure an empty slot (defined by a 32-bit zero pair) is recognized as
invalid.
DW_AT_main_subprogram is supported in normal mode in read_partial_die, but not
in -readnow mode.
Fix this by adding support for DW_AT_main_subprogram in read_func_scope.
Tested on x86_64-linux with native and RFC target board readnow (
https://sourceware.org/ml/gdb-patches/2019-05/msg00073.html ).
gdb/ChangeLog:
2019-06-10 Tom de Vries <tdevries@suse.de>
PR symtab/16264
PR symtab/24517
* dwarf2read.c (read_func_scope): Handle DW_AT_main_subprogram.
Ref.: https://bugzilla.redhat.com/show_bug.cgi?id=1715008
On commit 7bede82892 ("Don't crash if
dwarf_decode_macro_bytes's 'body' is NULL"), I was too strict when
checking if 'body' is NULL: the check only comprised the case when
'is_define' is true. However, the corruption of .debug_macro by
rpmbuild's "debugedit" also affects the case when 'is_define' is
false, i.e., when the macro is being undefined.
This commit improves the check and covers both cases now. This has
been tested on Fedora 30 with a problematic debuginfo, and I don't see
a segfault anymore.
OK to push?
gdb/ChangeLog:
2019-05-29 Sergio Durigan Junior <sergiodj@redhat.com>
Ref.: https://bugzilla.redhat.com/show_bug.cgi?id=1708192
Ref.: https://bugzilla.redhat.com/show_bug.cgi?id=1715008
* dwarf2read.c (dwarf_decode_macro_bytes): Move check to see if
'body' is NULL to the outter 'if', protecting the '!is_define'
situation as well.
I noticed that the complaint in partial_die_parent_scope was not using
dwarf_tag_name, so I changed that. Then I noticed that dwarf_tag_name
does not show the numeric value for an unrecognized tag, so I changed
that function and all the related functions to do so.
gdb/ChangeLog
2019-05-29 Tom Tromey <tromey@adacore.com>
* dwarf2read.c (partial_die_parent_scope): Call dwarf_tag_name.
(dwarf_unknown): New function.
(dwarf_tag_name, dwarf_attr_name, dwarf_form_name)
(dwarf_type_encoding_name): Use dwarf_unknown.
Adds a constructor to 'struct cu_partial_die_info' and disables the
default constructor, preventing partially initialised instances from
being created.
Update 'find_partial_die' to return a const struct.
Users of 'find_partial_die' are updated to take account of the above
two changes.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* dwarf2read.c (struct cu_partial_die_info): Add constructor,
delete default constructor.
(find_partial_die): Update to return const struct.
(partial_die_parent_scope): Move variable declaration into scope
of its use and change its type to auto.
(guess_partial_die_structure_name): Likewise.
(partial_die_info::fixup): Likewise.
When running gdb using AddressSanitizer, and loading a cc1plus binary built
with profiledbootstrap and -flto, we run into a heap-use-after-free error:
...
$ LD_PRELOAD=/usr/lib64/libasan.so.3 ./gdb -batch cc1plus
==26855==ERROR: AddressSanitizer: heap-use-after-free on address \
0x62100ad8a8b0 at pc 0x7f13803cc9e3 bp 0x7ffe55b0d090 sp 0x7ffe55b0c840
READ of size 47 at 0x62100ad8a8b0 thread T0
#0 0x7f13803cc9e2 (/usr/lib64/libasan.so.3+0x3e9e2)
#1 0x5e7a0d in typename_concat gdb/dwarf2read.c:22661
#2 0x5c6437 in partial_die_full_name gdb/dwarf2read.c:8876
#3 0x5c6555 in add_partial_symbol gdb/dwarf2read.c:8893
#4 0x5c6ecf in add_partial_subprogram gdb/dwarf2read.c:9156
#5 0x5c5e90 in scan_partial_symbols gdb/dwarf2read.c:8668
#6 0x5c6c0a in add_partial_namespace gdb/dwarf2read.c:9081
#7 0x5c5f99 in scan_partial_symbols gdb/dwarf2read.c:8702
#8 0x5c48b6 in process_psymtab_comp_unit_reader gdb/dwarf2read.c:8056
#9 0x5c3c1f in init_cutu_and_read_dies gdb/dwarf2read.c:7689
#10 0x5c4c03 in process_psymtab_comp_unit gdb/dwarf2read.c:8140
#11 0x5c58a2 in dwarf2_build_psymtabs_hard gdb/dwarf2read.c:8500
#12 0x5c0d03 in dwarf2_build_psymtabs(objfile*) gdb/dwarf2read.c:6337
#13 0x612359 in read_psyms gdb/elfread.c:1311
#14 0x798a64 in require_partial_symbols(objfile*, int) gdb/psymtab.c:115
#15 0x867d7b in read_symbols gdb/symfile.c:821
#16 0x8683d9 in syms_from_objfile_1 gdb/symfile.c:1000
#17 0x8684a1 in syms_from_objfile gdb/symfile.c:1017
#18 0x868873 in symbol_file_add_with_addrs gdb/symfile.c:1124
#19 0x868b0a in symbol_file_add_from_bfd(bfd*, char const*, \
enum_flags<symfile_add_flag>, std::vector<other_sections, \
std::allocator<other_sections> >*, \
enum_flags<objfile_flag>, objfile*) gdb/symfile.c:1204
#20 0x868b64 in symbol_file_add(char const*, \
enum_flags<symfile_add_flag>, \
std::vector<other_sections, \
std::allocator<other_sections> >*, \
enum_flags<objfile_flag>) gdb/symfile.c:1217
#21 0x868c39 in symbol_file_add_main_1 gdb/symfile.c:1240
#22 0x868bd0 in symbol_file_add_main(char const*, \
enum_flags<symfile_add_flag>) gdb/symfile.c:1231
#23 0x71f1b2 in symbol_file_add_main_adapter gdb/main.c:395
#24 0x71f10e in catch_command_errors gdb/main.c:372
#25 0x71ff5f in captured_main_1 gdb/main.c:1043
#26 0x72045d in captured_main gdb/main.c:1163
#27 0x7204c8 in gdb_main(captured_main_args*) gdb/main.c:1188
#28 0x40fd7d in main gdb/gdb.c:32
#29 0x7f137e300f49 in __libc_start_main (/lib64/libc.so.6+0x20f49)
#30 0x40fc89 in _start (/data/gdb_versions/devel/build/gdb/gdb+0x40fc89)
0x62100ad8a8b0 is located 944 bytes inside of 4064-byte region \
[0x62100ad8a500,0x62100ad8b4e0)
freed by thread T0 here:
#0 0x7f13804523a0 in __interceptor_free (/usr/lib64/libasan.so.3+0xc43a0)
#1 0x435e44 in xfree<void> gdb/common/common-utils.h:60
#2 0xa82c25 in call_freefun libiberty/obstack.c:103
#3 0xa83098 in _obstack_free libiberty/obstack.c:280
#4 0x4367da in auto_obstack::~auto_obstack() gdb/gdb_obstack.h:101
#5 0x5ed72c in dwarf2_cu::~dwarf2_cu() gdb/dwarf2read.c:25341
#6 0x5fb5bb in std::default_delete<dwarf2_cu>::operator()(dwarf2_cu*) const \
/usr/include/c++/7/bits/unique_ptr.h:78
#7 0x5f7334 in std::unique_ptr<dwarf2_cu, \
std::default_delete<dwarf2_cu> >::~unique_ptr() \
/usr/include/c++/7/bits/unique_ptr.h:268
#8 0x5c3ce5 in init_cutu_and_read_dies gdb/dwarf2read.c:7624
#9 0x5c4c03 in process_psymtab_comp_unit gdb/dwarf2read.c:8140
#10 0x5c58a2 in dwarf2_build_psymtabs_hard gdb/dwarf2read.c:8500
#11 0x5c0d03 in dwarf2_build_psymtabs(objfile*) gdb/dwarf2read.c:6337
#12 0x612359 in read_psyms gdb/elfread.c:1311
#13 0x798a64 in require_partial_symbols(objfile*, int) gdb/psymtab.c:115
#14 0x867d7b in read_symbols gdb/symfile.c:821
#15 0x8683d9 in syms_from_objfile_1 gdb/symfile.c:1000
#16 0x8684a1 in syms_from_objfile gdb/symfile.c:1017
#17 0x868873 in symbol_file_add_with_addrs gdb/symfile.c:1124
#18 0x868b0a in symbol_file_add_from_bfd(bfd*, char const*, \
enum_flags<symfile_add_flag>, std::vector<other_sections, \
std::allocator<other_sections> >*, \
enum_flags<objfile_flag>, objfile*) gdb/symfile.c:1204
#19 0x868b64 in symbol_file_add(char const*, \
enum_flags<symfile_add_flag>, std::vector<other_sections, \
std::allocator<other_sections> >*, \
enum_flags<objfile_flag>) gdb/symfile.c:1217
#20 0x868c39 in symbol_file_add_main_1 gdb/symfile.c:1240
#21 0x868bd0 in symbol_file_add_main(char const*, \
enum_flags<symfile_add_flag>) gdb/symfile.c:1231
#22 0x71f1b2 in symbol_file_add_main_adapter gdb/main.c:395
#23 0x71f10e in catch_command_errors gdb/main.c:372
#24 0x71ff5f in captured_main_1 gdb/main.c:1043
#25 0x72045d in captured_main gdb/main.c:1163
#26 0x7204c8 in gdb_main(captured_main_args*) gdb/main.c:1188
#27 0x40fd7d in main gdb/gdb.c:32
#28 0x7f137e300f49 in __libc_start_main (/lib64/libc.so.6+0x20f49)
previously allocated by thread T0 here:
#0 0x7f13804526b8 in __interceptor_malloc (/usr/lib64/libasan.so.3+0xc46b8)
#1 0x5114b5 in xmalloc gdb/common/common-utils.c:44
#2 0xa82bd5 in call_chunkfun libiberty/obstack.c:94
#3 0xa82eda in _obstack_newchunk libiberty/obstack.c:206
#4 0x477310 in allocate_on_obstack::operator new(unsigned long, obstack*) \
gdb/gdb_obstack.h:117
#5 0x5dea8c in load_partial_dies gdb/dwarf2read.c:18571
#6 0x5c487f in process_psymtab_comp_unit_reader gdb/dwarf2read.c:8054
#7 0x5c3c1f in init_cutu_and_read_dies gdb/dwarf2read.c:7689
#8 0x5c4c03 in process_psymtab_comp_unit gdb/dwarf2read.c:8140
#9 0x5c58a2 in dwarf2_build_psymtabs_hard gdb/dwarf2read.c:8500
#10 0x5c0d03 in dwarf2_build_psymtabs(objfile*) gdb/dwarf2read.c:6337
#11 0x612359 in read_psyms gdb/elfread.c:1311
#12 0x798a64 in require_partial_symbols(objfile*, int) gdb/psymtab.c:115
#13 0x867d7b in read_symbols gdb/symfile.c:821
#14 0x8683d9 in syms_from_objfile_1 gdb/symfile.c:1000
#15 0x8684a1 in syms_from_objfile gdb/symfile.c:1017
#16 0x868873 in symbol_file_add_with_addrs gdb/symfile.c:1124
#17 0x868b0a in symbol_file_add_from_bfd(bfd*, char const*, \
enum_flags<symfile_add_flag>, \
std::vector<other_sections, \
std::allocator<other_sections> >*, \
enum_flags<objfile_flag>, objfile*) gdb/symfile.c:1204
#18 0x868b64 in symbol_file_add(char const*, enum_flags<symfile_add_flag>, \
std::vector<other_sections, \
std::allocator<other_sections> >*, \
enum_flags<objfile_flag>) gdb/symfile.c:1217
#19 0x868c39 in symbol_file_add_main_1 gdb/symfile.c:1240
#20 0x868bd0 in symbol_file_add_main(char const*, \
enum_flags<symfile_add_flag>) gdb/symfile.c:1231
#21 0x71f1b2 in symbol_file_add_main_adapter gdb/main.c:395
#22 0x71f10e in catch_command_errors gdb/main.c:372
#23 0x71ff5f in captured_main_1 gdb/main.c:1043
#24 0x72045d in captured_main gdb/main.c:1163
#25 0x7204c8 in gdb_main(captured_main_args*) gdb/main.c:1188
#26 0x40fd7d in main gdb/gdb.c:32
#27 0x7f137e300f49 in __libc_start_main (/lib64/libc.so.6+0x20f49)
...
This error happens as follows.
The function find_partial_die has a cu argument, but returns a pdi which may
or may not be from that cu:
...
/* Find a partial DIE at OFFSET, which may or may not be in CU,
except in the case of .debug_types DIEs which do not reference
outside their CU (they do however referencing other types via
DW_FORM_ref_sig8). */
static struct partial_die_info *
find_partial_die (sect_offset sect_off, int offset_in_dwz, struct dwarf2_cu *cu)
...
So the pdi returned by find_partial_die here in partial_die_parent_scope may
be from another cu:
...
partial_die_parent_scope (struct partial_die_info *pdi,
struct dwarf2_cu *cu)
{
const char *grandparent_scope;
struct partial_die_info *parent, *real_pdi;
/* We need to look at our parent DIE; if we have a DW_AT_specification,
then this means the parent of the specification DIE. */
real_pdi = pdi;
while (real_pdi->has_specification)
real_pdi = find_partial_die (real_pdi->spec_offset,
real_pdi->spec_is_dwz, cu);
parent = real_pdi->die_parent;
...
in which case both real_pdi and parent will be not from cu, but from another
one, say cu2.
Subsequently, cu's comp_unit_obstack is used to set parent->scope:
...
parent->scope = typename_concat (&cu->comp_unit_obstack,
grandparent_scope,
parent->name, 0, cu);
...
So, we use cu->comp_unit_obstack to assign a value to the scope field of
a pdi belonging to cu2, and when cu is deleted, the scope field points to a
freed value.
Fix this by making find_partial_die return the cu corresponding to the
returned pdi, and handling this at the call sites.
Tested on x86_64-linux.
gdb/ChangeLog:
2019-05-17 Tom de Vries <tdevries@suse.de>
PR gdb/24094
* dwarf2read.c (struct cu_partial_die_info): New struct.
(find_partial_die): Return cu_partial_die_info.
(partial_die_parent_scope, guess_partial_die_structure_name)
(partial_die_info::fixup): Handle new return type of find_partial_die.
Hi,
Ref.: https://bugzilla.redhat.com/show_bug.cgi?id=1708192https://bugzilla.redhat.com/show_bug.cgi?id=1708786
During the Fedora RPM build process, gdb-add-index is invoked to
extract the DWARF index from the binary, and GDB will segfault because
dwarf2read.c:parse_definition_macro's 'body' variable is NULL.
The underlying problem is that Fedora's rpm-build's "debugedit"
program will silently corrupt .debug_macro strings when a binary is
compiled with -g3. This is being taken care of by Mark Wielaard,
here:
https://bugzilla.redhat.com/show_bug.cgi?id=1708786
However, I still feel it's important to make GDB more resilient
against invalid DWARF input, so I'm proposing this rather simple patch
to catch the situation when "body == NULL" (i.e., it's probably been
corrupted) and issue a complaint. This is not a real fix to the
problem, of course, but at least GDB is able to finish without
segfaulting.
OK for master?
gdb/ChangeLog:
2019-05-15 Sergio Durigan Junior <sergiodj@redhat.com>
Ref.: https://bugzilla.redhat.com/show_bug.cgi?id=1708192
* dwarf2read.c (dwarf_decode_macro_bytes): Check whether 'body' is
NULL, and complain if that's the case.
This changes dwarf2_per_objfile to use the type-safe registry API.
This also changes dwarf2_per_objfile not to be allocated on an
obstack. It seemed clearer to me to simply allocate it on the heap;
and I didn't see a drawback from doing so.
gdb/ChangeLog
2019-05-08 Tom Tromey <tom@tromey.com>
* dwarf2read.h (struct dwarf2_per_objfile): Don't inherit from
allocate_on_obstack.
* dwarf2read.c (dwarf2_objfile_data_key): Change type.
(get_dwarf2_per_objfile): Update.
(set_dwarf2_per_objfile): Remove.
(dwarf2_has_info, dwarf2_get_section_info): Update.
(dwarf2_free_objfile): Remove.
(_initialize_dwarf2_read): Update.
Some versions of gcc have a bug that causes
for (struct mumble : something)
... to give a compiler error. We routinely work around this bug in
gdb, but apparently had not done so in a while. This patch fixes the
remaining known cases of this problem.
gdb/ChangeLog
2019-05-03 Sandra Loosemore <sandra@codesourcery.com>
Tom Tromey <tom@tromey.com>
* dictionary.c (collate_pending_symbols_by_language): Remove
"struct" from foreach.
* symtab.c (lookup_global_symbol_from_objfile)
(lookup_symbol_in_objfile_from_linkage_name): Remove "struct" from
foreach.
* ser-tcp.c (net_open): Remove "struct" from foreach.
* objfiles.c (objfile_relocate, objfile_rebase)
(objfile_has_symbols): Remove "struct" from foreach.
* minsyms.c (lookup_minimal_symbol_by_pc_section): Remove "struct"
from foreach.
* dwarf2read.c (handle_struct_member_die): Remove "struct" from
foreach.
* darwin-nat.c (thread_info_from_private_thread_info): Remove
"struct" from foreach.
* ada-lang.c (create_excep_cond_exprs)
(ada_exception_catchpoint_cond_string): Remove "struct" from
foreach.
Dwarf5 defines DW_FORM_strx1 and others, which are similar
to DW_FORM_strx but uses 1-4 bytes unsigned integers. This is
a small step towards supporting dwarf5 in gdb.
PR c++/24470 concerns a crash in dwarf2read.c that occurs with a
particular test case.
The issue turns out to be that process_structure_scope will pass NULL
to symbol_symtab. This happens because new_symbol decided not to
create a symbol for the particular DIE.
This patch fixes the problem by finding another reasonably-appropriate
symtab to use instead; issuing a complaint if one cannot be found for
some reason.
As mentioned in the bug, I think there are other bugs here. For
example, when using "ptype" on the "l" object in the test case, I
think I would expect to see the template parameter. I didn't research
this too closely, since it seemed more important to fix the crash.
Tested on x86-64 Fedora 29.
I'd like to check this in to the 8.3 branch as well.
2019-04-30 Tom Tromey <tromey@adacore.com>
PR c++/24470:
* dwarf2read.c (process_structure_scope): Handle case where type
has template parameters but no symbol was created.
gdb/testsuite/ChangeLog
2019-04-30 Tom Tromey <tromey@adacore.com>
PR c++/24470:
* gdb.cp/temargs.cc: Add test code from PR.
Currently when using $_creal and $_cimag to access the components of a
complex number the types of these components will have C type names
'float', 'double', etc. This is because the components of a complex
number are not given type names in DWARF, so GDB has to pick some
suitable names, and currently we always use the C names.
This commit changes the type names used based on the language, so for
Fortran we will now use the Fortran float types, and so will get the
Fortran float type names 'real', 'real*8', etc.
gdb/ChangeLog:
* dwarf2read.c (dwarf2_init_complex_target_type): Use different
types for Fortran.
gdb/testsuite/ChangeLog:
* gdb.fortran/complex.exp: Expand.
* gdb.fortran/complex.f: Renamed to...
* gdb.fortran/complex.f90: ...this, and extended to add more
complex values.
I noticed that one of the overloads of line_header::file_name_at is
unused. This patch removes it.
gdb/ChangeLog
2019-04-23 Tom Tromey <tromey@adacore.com>
* dwarf2read.c (line_header::file_name_at): Remove unused
overload.
DW_OP_addrx is the new name of DW_OP_GNU_addr_index, and DW_FORM_addrx
is the name of DW_FORM_addr_index in the Dwarf 5 standard. This is a small
step towards supporting Dwarf 5 in gdb.
Note: I could not find any tests specifically for *_GNU_addr_index, and
I did not add any new tests, please advise.
After commit 35add35 ("gdb: Fix failure in gdb.base/complex-parts.exp
for x86-32"), dwarf2_init_complex_target_type can crash if "tt" is
nullptr. This patch avoids the problem by checking for this case.
No test case because I don't know a good way to write one; it was
found by an internal AdaCore test case that apparently uses a 16 bit
floating point type.
gdb/ChangeLog:
* dwarf2read.c (dwarf2_init_complex_target_type): Check "tt"
against nullptr before use.
gdb/ChangeLog
2019-04-17 Tom Tromey <tromey@adacore.com>
* dwarf2read.c (dwarf2_init_complex_target_type): Check "tt"
against nullptr before use.
The x86-32 ABI specifies 96-bit long double, this was causing a
failure on the test gdb.base/complex-parts.exp.
The problem is that GDB tries to find a builtin floating point type of
the correct size in order to reuse the name of that type as the name
for the components of the complex type being built.
Previously GDB was only aware of floating point types sized 32, 64, or
128 bits. This patch teaches GDB how to handle 96 bit floating point
type.
gdb/ChangeLog:
* dwarf2read.c (dwarf2_init_complex_target_type): Handle complex
target types of size 96-bits, add some additional comments, and
check that the builtin type we found was the correct size.
This rewrites gdb's TRY/CATCH to plain C++ try/catch. The patch was
largely written by script, though one change (to a comment in
common-exceptions.h) was reverted by hand.
gdb/ChangeLog
2019-04-08 Tom Tromey <tom@tromey.com>
* xml-support.c: Use C++ exception handling.
* x86-linux-nat.c: Use C++ exception handling.
* windows-nat.c: Use C++ exception handling.
* varobj.c: Use C++ exception handling.
* value.c: Use C++ exception handling.
* valprint.c: Use C++ exception handling.
* valops.c: Use C++ exception handling.
* unittests/parse-connection-spec-selftests.c: Use C++ exception
handling.
* unittests/cli-utils-selftests.c: Use C++ exception handling.
* typeprint.c: Use C++ exception handling.
* tui/tui.c: Use C++ exception handling.
* tracefile-tfile.c: Use C++ exception handling.
* top.c: Use C++ exception handling.
* thread.c: Use C++ exception handling.
* target.c: Use C++ exception handling.
* symmisc.c: Use C++ exception handling.
* symfile-mem.c: Use C++ exception handling.
* stack.c: Use C++ exception handling.
* sparc64-linux-tdep.c: Use C++ exception handling.
* solib.c: Use C++ exception handling.
* solib-svr4.c: Use C++ exception handling.
* solib-spu.c: Use C++ exception handling.
* solib-frv.c: Use C++ exception handling.
* solib-dsbt.c: Use C++ exception handling.
* selftest-arch.c: Use C++ exception handling.
* s390-tdep.c: Use C++ exception handling.
* rust-lang.c: Use C++ exception handling.
* rust-exp.y: Use C++ exception handling.
* rs6000-tdep.c: Use C++ exception handling.
* rs6000-aix-tdep.c: Use C++ exception handling.
* riscv-tdep.c: Use C++ exception handling.
* remote.c: Use C++ exception handling.
* remote-fileio.c: Use C++ exception handling.
* record-full.c: Use C++ exception handling.
* record-btrace.c: Use C++ exception handling.
* python/python.c: Use C++ exception handling.
* python/py-value.c: Use C++ exception handling.
* python/py-utils.c: Use C++ exception handling.
* python/py-unwind.c: Use C++ exception handling.
* python/py-type.c: Use C++ exception handling.
* python/py-symbol.c: Use C++ exception handling.
* python/py-record.c: Use C++ exception handling.
* python/py-record-btrace.c: Use C++ exception handling.
* python/py-progspace.c: Use C++ exception handling.
* python/py-prettyprint.c: Use C++ exception handling.
* python/py-param.c: Use C++ exception handling.
* python/py-objfile.c: Use C++ exception handling.
* python/py-linetable.c: Use C++ exception handling.
* python/py-lazy-string.c: Use C++ exception handling.
* python/py-infthread.c: Use C++ exception handling.
* python/py-inferior.c: Use C++ exception handling.
* python/py-gdb-readline.c: Use C++ exception handling.
* python/py-framefilter.c: Use C++ exception handling.
* python/py-frame.c: Use C++ exception handling.
* python/py-finishbreakpoint.c: Use C++ exception handling.
* python/py-cmd.c: Use C++ exception handling.
* python/py-breakpoint.c: Use C++ exception handling.
* python/py-arch.c: Use C++ exception handling.
* printcmd.c: Use C++ exception handling.
* ppc-linux-tdep.c: Use C++ exception handling.
* parse.c: Use C++ exception handling.
* p-valprint.c: Use C++ exception handling.
* objc-lang.c: Use C++ exception handling.
* mi/mi-main.c: Use C++ exception handling.
* mi/mi-interp.c: Use C++ exception handling.
* mi/mi-cmd-stack.c: Use C++ exception handling.
* mi/mi-cmd-break.c: Use C++ exception handling.
* main.c: Use C++ exception handling.
* linux-thread-db.c: Use C++ exception handling.
* linux-tdep.c: Use C++ exception handling.
* linux-nat.c: Use C++ exception handling.
* linux-fork.c: Use C++ exception handling.
* linespec.c: Use C++ exception handling.
* language.c: Use C++ exception handling.
* jit.c: Use C++ exception handling.
* infrun.c: Use C++ exception handling.
* infcmd.c: Use C++ exception handling.
* infcall.c: Use C++ exception handling.
* inf-loop.c: Use C++ exception handling.
* i386-tdep.c: Use C++ exception handling.
* i386-linux-tdep.c: Use C++ exception handling.
* guile/scm-value.c: Use C++ exception handling.
* guile/scm-type.c: Use C++ exception handling.
* guile/scm-symtab.c: Use C++ exception handling.
* guile/scm-symbol.c: Use C++ exception handling.
* guile/scm-pretty-print.c: Use C++ exception handling.
* guile/scm-ports.c: Use C++ exception handling.
* guile/scm-param.c: Use C++ exception handling.
* guile/scm-math.c: Use C++ exception handling.
* guile/scm-lazy-string.c: Use C++ exception handling.
* guile/scm-frame.c: Use C++ exception handling.
* guile/scm-disasm.c: Use C++ exception handling.
* guile/scm-cmd.c: Use C++ exception handling.
* guile/scm-breakpoint.c: Use C++ exception handling.
* guile/scm-block.c: Use C++ exception handling.
* guile/guile-internal.h: Use C++ exception handling.
* gnu-v3-abi.c: Use C++ exception handling.
* gdbtypes.c: Use C++ exception handling.
* frame.c: Use C++ exception handling.
* frame-unwind.c: Use C++ exception handling.
* fbsd-tdep.c: Use C++ exception handling.
* f-valprint.c: Use C++ exception handling.
* exec.c: Use C++ exception handling.
* event-top.c: Use C++ exception handling.
* event-loop.c: Use C++ exception handling.
* eval.c: Use C++ exception handling.
* dwarf2read.c: Use C++ exception handling.
* dwarf2loc.c: Use C++ exception handling.
* dwarf2-frame.c: Use C++ exception handling.
* dwarf2-frame-tailcall.c: Use C++ exception handling.
* dwarf-index-write.c: Use C++ exception handling.
* dwarf-index-cache.c: Use C++ exception handling.
* dtrace-probe.c: Use C++ exception handling.
* disasm-selftests.c: Use C++ exception handling.
* darwin-nat.c: Use C++ exception handling.
* cp-valprint.c: Use C++ exception handling.
* cp-support.c: Use C++ exception handling.
* cp-abi.c: Use C++ exception handling.
* corelow.c: Use C++ exception handling.
* completer.c: Use C++ exception handling.
* compile/compile-object-run.c: Use C++ exception handling.
* compile/compile-object-load.c: Use C++ exception handling.
* compile/compile-cplus-symbols.c: Use C++ exception handling.
* compile/compile-c-symbols.c: Use C++ exception handling.
* common/selftest.c: Use C++ exception handling.
* common/new-op.c: Use C++ exception handling.
* cli/cli-script.c: Use C++ exception handling.
* cli/cli-interp.c: Use C++ exception handling.
* cli/cli-cmds.c: Use C++ exception handling.
* c-varobj.c: Use C++ exception handling.
* btrace.c: Use C++ exception handling.
* breakpoint.c: Use C++ exception handling.
* break-catch-throw.c: Use C++ exception handling.
* arch-utils.c: Use C++ exception handling.
* amd64-tdep.c: Use C++ exception handling.
* ada-valprint.c: Use C++ exception handling.
* ada-typeprint.c: Use C++ exception handling.
* ada-lang.c: Use C++ exception handling.
* aarch64-tdep.c: Use C++ exception handling.
gdb/gdbserver/ChangeLog
2019-04-08 Tom Tromey <tom@tromey.com>
* server.c: Use C++ exception handling.
* linux-low.c: Use C++ exception handling.
* gdbreplay.c: Use C++ exception handling.
Add two new internal functions $_cimag and $_creal that extract the
imaginary and real parts of a complex value.
These internal functions can take a complex value of any type 'float
complex', 'double complex', or 'long double complex' and return a
suitable floating point value 'float', 'double', or 'long double'.
So we can now do this:
(gdb) p z1
$1 = 1.5 + 4.5 * I
(gdb) p $_cimag (z1)
$4 = 4.5
(gdb) p $_creal (z1)
$4 = 1.5
The components of a complex value are not strictly named types in
DWARF, as the complex type is itself the base type. However, once we
are able to extract the components it makes sense to be able to ask
what the type of these components is and get a sensible answer back,
rather than the error we would currently get. Currently GDB says:
(gdb) ptype z1
type = complex double
(gdb) p $_cimag (z1)
$4 = 4.5
(gdb) ptype $
type = <invalid type code 9>
With the changes in dwarf2read.c, GDB now says:
(gdb) ptype z1
type = complex double
(gdb) p $_cimag (z1)
$4 = 4.5
(gdb) ptype $
type = double
Which seems to make more sense.
gdb/ChangeLog:
* NEWS: Mention new internal functions.
* dwarf2read.c (dwarf2_init_complex_target_type): New function.
(read_base_type): Use dwarf2_init_complex_target_type.
* value.c (creal_internal_fn): New function.
(cimag_internal_fn): New function.
(_initialize_values): Register new internal functions.
gdb/doc/ChangeLog:
* gdb.texinfo (Convenience Funs): Document '$_creal' and
'$_cimag'.
gdb/testsuite/ChangeLog:
* gdb.base/complex-parts.c: New file.
* gdb.base/complex-parts.exp: New file.
add_partial_subprogram does not handle DW_AT_ranges, while the full
symtab reader does. This can lead to discrepancies where a function
is not put into a partial symtab, and so is not available to "break"
and the like -- but is available if the full symtab has somehow been
read.
This patch fixes the bug by arranging to read DW_AT_ranges when
reading partial DIEs.
This is PR symtab/23331.
The new test case is derived from dw2-ranges-func.exp, which is why I
kept the copyright dates.
gdb/ChangeLog
2019-04-01 Tom Tromey <tromey@adacore.com>
PR symtab/23331:
* dwarf2read.c (partial_die_info::read): Handle DW_AT_ranges.
gdb/testsuite/ChangeLog
2019-04-01 Tom Tromey <tromey@adacore.com>
PR symtab/23331:
* gdb.dwarf2/dw2-ranges-main.c: New file.
* gdb.dwarf2/dw2-ranges-psym.c: New file.
* gdb.dwarf2/dw2-ranges-psym.exp: New file.
I noticed that there are still many places referring to non-const
blocks. This constifies all the remaining ones that I found that
could be constified.
In a few spots, this search found unused variables or fields. I
removed these. I've also removed some unnecessary casts to
"struct block *".
gdb/ChangeLog
2019-03-24 Tom Tromey <tom@tromey.com>
* c-exp.y (typebase): Remove casts.
* gdbtypes.c (lookup_unsigned_typename, )
(lookup_signed_typename): Remove cast.
* eval.c (parse_to_comma_and_eval): Remove cast.
* parse.c (write_dollar_variable): Remove cast.
* block.h (struct block) <superblock>: Now const.
* symfile-debug.c (debug_qf_map_matching_symbols): Update.
* psymtab.c (psym_map_matching_symbols): Make "block" const.
(map_block): Make "block" const.
* symfile.h (struct quick_symbol_functions)
<map_matching_symbols>: Constify block argument to "callback".
* symtab.c (basic_lookup_transparent_type_quick): Make "block"
const.
(find_pc_sect_compunit_symtab): Make "b" const.
(find_symbol_at_address): Likewise.
(search_symbols): Likewise.
* dwarf2read.c (dw2_lookup_symbol): Make "block" const.
(dw2_debug_names_lookup_symbol): Likewise.
(dw2_map_matching_symbols): Update.
* p-valprint.c (pascal_val_print): Remove "block".
* ada-lang.c (ada_add_global_exceptions): Make "b" const.
(aux_add_nonlocal_symbols): Make "block" const.
(resolve_subexp): Remove cast.
* linespec.c (iterate_over_all_matching_symtabs): Make "block"
const.
(iterate_over_file_blocks): Likewise.
* f-exp.y (%union) <bval>: Remove.
* coffread.c (patch_opaque_types): Make "b" const.
* spu-tdep.c (spu_catch_start): Make "block" const.
* c-valprint.c (print_unpacked_pointer): Remove "block".
* symmisc.c (dump_symtab_1): Make "b" const.
(block_depth): Make "block" const.
* d-exp.y (%union) <bval>: Remove.
* cp-support.h (cp_lookup_rtti_type): Update.
* cp-support.c (cp_lookup_rtti_type): Make "block" const.
* psymtab.c (psym_lookup_symbol): Make "block" const.
(maintenance_check_psymtabs): Make "b" const.
* python/py-framefilter.c (extract_sym): Make "sym_block" const.
(enumerate_locals, enumerate_args): Update.
* python/py-symtab.c (stpy_global_block): Make "block" const.
(stpy_static_block): Likewise.
* inline-frame.c (block_starting_point_at): Make "new_block"
const.
* block.c (find_block_in_blockvector): Make return type const.
(blockvector_for_pc_sect): Make "b" const.
(find_block_in_blockvector): Make "b" const.
dwarf2_find_containing_comp_unit has two assignments to "this_cu" in
quick succession, both of which are just:
this_cu = dwarf2_per_objfile->all_comp_units[low];
... with no intervening assignments.
This patch removes the second assignment. I'm checking this in as
obvious. Tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-03-11 Tom Tromey <tromey@adacore.com>
* dwarf2read.c (dwarf2_find_containing_comp_unit): Remove
redundant assignment to "this_cu".
Previously if build_id_verify failed, dwz_bfd was cleared to NULL via
release(), but the BFD object was not destroyed. Use reset() with
nullptr instead to delete the BFD.
gdb/ChangeLog:
* dwarf2read.c (dwarf2_get_dwz_file): Reset dwz_bfd to nullptr
instead of releasing ownership.
When loading dwp files, we create an array of ELF sections indexed by the ELF
section index in the dwp file. The size of this array is calculated by
section_count, as returned by bfd_count_sections, plus 1 (to account for the
null section at index 0). However, when loading the bfd file, strtab/symtab
sections are not added to the list, nor do they increment section_count, so
section_count is actually smaller than the number of ELF sections.
This happens to work when using GNU dwp, which lays out .debug section first,
with sections like .shstrtab coming at the end. Other tools, like llvm-dwp, put
.strtab first, and gdb crashes when loading those dwp files.
For instance, with the current state of gdb, loading a file like this:
$ readelf -SW <file.dwp>
[ 0] <empty>
[ 1] .debug_foo PROGBITS ...
[ 2] .strtab STRTAB ...
... results in section_count = 2 (.debug is the only thing placed into
bfd->sections, so section_count + 1 == 2), and sectp->this_idx = 1 when mapping
over .debug_foo in dwarf2_locate_common_dwp_sections, which passes the
assertion that 1 < 2.
However, using a dwp file produced by llvm-dwp:
$ readelf -SW <file.dwp>
[ 0] <empty>
[ 1] .strtab STRTAB ...
[ 2] .debug_foo PROGBITS ...
... results in section_count = 2 (.debug is the only thing placed into
bfd->sections, so section_count + 1 == 2), and sectp->this_idx = 2 when mapping
over .debug_foo in dwarf2_locate_common_dwp_sections, which fails the assertion
that 2 < 2.
The assertion hit is:
gdb/dwarf2read.c:13009: internal-error: void dwarf2_locate_common_dwp_sections(bfd*, asection*, void*): Assertion `elf_section_nr < dwp_file->num_sections' failed.
This patch changes the calculation of section_count to use elf_numsections,
which should return the actual number of ELF sections.
This patch is an attempt to deal with a variety of bugs reported where
GDB segfaults attempting to access a dwarf2_cu's builder. In certain
circumstances, this builder can be NULL. This is especially common
when inheriting DIEs via inlined subroutines in other CUs. The test
case demonstrates one such situation reported by users. See gdb/23773,
rhbz1638798, and dups for other concrete examples.
The approach taken here is to save the ancestor CU into the dwarf2_cu of
all CUs with DIEs that are "imported." This can happen whenever
follow_die_offset and friends are called. This essentially introduces a
chain of CUs that caused the importation of a DIE from a CU. Whenever
a builder is requested of a CU that has none, the ancestors are searched
for the first one with a builder.
A design side effect of this is that the builder can now only be
accessed by getter and setter methods because the builder itself
is private.
The bulk of the patch is relatively mindless text conversion from
"cu->builder" to "cu->get_builder ()". I've included one test which
was derived from one (of the many) bugs reported on the issue in both
sourceware and Fedora bugzillas.
gdb/ChangeLog:
PR gdb/23773
* dwarf2read.c (dwarf2_cu) <ancestor>: New field.
<builder>: Rename to ..
<m_builder>: ... this and make private.
(dwarf2_cu::get_builder): New method. Change all users of
`builder' to use this method.
(dwarf2_start_symtab): Move to ...
(dwarf2_cu::start_symtab): ... here. Update all callers
(setup_type_unit_groups): Move to ...
(dwarf2_cu::setup_type_unit_groups): ... here. Update all
callers.
(dwarf2_cu::reset_builder): New method.
(process_full_compunit, process_full_type_unit): Use
dwarf2_cu::reset_builder.
(follow_die_offset): Record the ancestor CU if it is different
from the followed DIE's CU.
(follow_die_sig_1): Likewise.
gdb/testsuite/ChangeLog:
PR gdb/23773
* gdb.dwarf2/inlined_subroutine-inheritance.exp: New file.
Finally, we can remove dw2_add_symbol_to_list since the wrapper function
originally introduced to catch this multi-language scenario is no longer
needed. With multi-language dictionaries, we can now support adding
symbols of multiple languages, negating the need for the assertion
entirely.
This patch should now fix gdb/23712 (and symtab/23010). At least it will
if the NULL buildsym_compunit problem doesn't strike first (see gdb/23773).
gdb/ChangeLog:
PR gdb/23712
PR symtab/23010
* dwarf2read.c (dw2_add_symbol_to_list): Remove.
(fixup_go_packaging, new_symbol): Use add_symbol_to_list.
This adds a new method to psymtab_storage to allocate storage for
psymtab dependencies, then changes the symbol readers to use it. This
has the effect of moving the storage to the psymtab storage obstack.
gdb/ChangeLog
2019-01-10 Tom Tromey <tom@tromey.com>
* xcoffread.c (xcoff_end_psymtab): Use allocate_dependencies.
* psymtab.h (psymtab_storage::allocate_dependencies): New method.
* mdebugread.c (parse_partial_symbols): Use
allocate_dependencies.
* dwarf2read.c (dwarf2_create_include_psymtab): Use
allocate_dependencies.
(process_psymtab_comp_unit_reader)
(build_type_psymtab_dependencies): Likewise.
* dbxread.c (dbx_end_psymtab): Use allocate_dependencies.
After this patch, the psymtab address map will now be allocated on the
psymtab obstack rather than the objfile obstack. This also changes
the psymtab storage object to make the obstack private; this will be
used later.
gdb/ChangeLog
2019-01-10 Tom Tromey <tom@tromey.com>
* psymtab.h (psymtab_storage::obstack): New method.
<m_obstack>: Rename from obstack; now private.
* psymtab.c (psymtab_storage): Update.
* dwarf2read.c (create_addrmap_from_index)
(create_addrmap_from_aranges, dwarf2_build_psymtabs_hard):
Update.
This introduces a new psymtab_storage class, which holds all
psymbol-related objects that are independent of the objfile. (This
latter contraint explains why psymbol_map was not moved; though this
could still be done with some work.)
This patch does not yet change where psymtab allocation is done --
that comes later. This just wraps everything in a single object to
make further transformations simpler.
Note that a shared_ptr is used to link from the objfile to the
psymtab_storage object. The end goal here is to allow a given symbol
reader to simply attach to the psymtab_storage object to the BFD, then
reuse it in later invocations; shared_ptr makes this simple to reason
about.
gdb/ChangeLog
2019-01-10 Tom Tromey <tom@tromey.com>
* symmisc.c (print_symbol_bcache_statistics): Update.
(print_objfile_statistics): Update.
* symfile.c (reread_symbols): Update.
* psymtab.h (class psymtab_storage): New.
* psymtab.c (psymtab_storage): New constructor.
(~psymtab_storage): New destructor.
(require_partial_symbols): Update.
(ALL_OBJFILE_PSYMTABS_REQUIRED): Rewrite.
(find_pc_sect_psymtab, find_pc_sect_psymbol)
(match_partial_symbol, lookup_partial_symbol, dump_psymtab)
(psym_dump, recursively_search_psymtabs, psym_has_symbols)
(psym_find_compunit_symtab_by_address, sort_pst_symbols)
(start_psymtab_common, end_psymtab_common)
(add_psymbol_to_bcache, add_psymbol_to_list, init_psymbol_list)
(allocate_psymtab): Update.
(psymtab_storage::discard_psymtab): Rename from discard_psymtab.
Update.
(dump_psymtab_addrmap, maintenance_print_psymbols)
(maintenance_check_psymtabs): Update.
(class objfile_psymtabs): Move to objfiles.h.
* psympriv.h (discard_psymtab): Now inline.
(psymtab_discarder::psymtab_discarder): Update.
(psymtab_discarder::~psymtab_discarder): Update.
(ALL_OBJFILE_PSYMTABS): Rewrite.
* objfiles.h (struct objfile) <psymtabs, psymtabs_addrmap,
free_psymtabs, psymbol_cache, global_psymbols, static_psymbols>:
Remove fields.
<partial_symtabs>: New field.
(class objfile_psymtabs): Move from psymtab.h. Update.
* objfiles.c (objfile::objfile): Initialize partial_symtabs, not
psymbol_cache.
(objfile::~objfile): Don't destroy psymbol_cache.
* mdebugread.c (parse_partial_symbols): Update.
* dwarf2read.c (create_addrmap_from_index)
(create_addrmap_from_aranges, dw2_find_pc_sect_compunit_symtab)
(process_psymtab_comp_unit_reader, dwarf2_build_psymtabs_hard)
(add_partial_subprogram, dwarf2_ranges_read): Update.
* dwarf-index-write.c (write_address_map)
(write_one_signatured_type, recursively_write_psymbols)
(class debug_names, class debug_names, write_psymtabs_to_index):
Update.
Existing callers to init_psymbol_list were checking to see if psymbols
had already been initialized. It seemed better to me to do this check
directly in init_psymbol_list, simplifying the callers.
gdb/ChangeLog
2019-01-10 Tom Tromey <tom@tromey.com>
* xcoffread.c (xcoff_initial_scan): Unconditionally call
init_psymbol_list.
* psymtab.c (init_psymbol_list): Do nothing if already called.
* psympriv.h (init_psymbol_list): Add comment.
* dwarf2read.c (dwarf2_build_psymtabs): Unconditionally call
init_psymbol_list.
* dbxread.c (dbx_symfile_read): Unconditionally call
init_psymbol_list.
This changes add_psymbol_to_list to use an enum, rather than a pointer
to a vector, to decide where to put the new symbol. This reduces the
number of direct references to the static_psymbols and global_psymbols
members of the objfile, which is handy in a later patch.
gdb/ChangeLog
2019-01-10 Tom Tromey <tom@tromey.com>
* xcoffread.c (scan_xcoff_symtab): Update.
* psymtab.c (add_psymbol_to_list): Replace "list" parameter with
"where".
* mdebugread.c (parse_partial_symbols)
(handle_psymbol_enumerators): Update.
* dwarf2read.c (add_partial_symbol, load_partial_dies): Update.
* dbxread.c (read_dbx_symtab): Update.
* psympriv.h (psymbol_placement): New enum.
(add_psymbol_to_list): Update.
start_psymtab_common takes references to the global_psymbols and
static_psymbols vectors, but it also has an objfile parameter. This
is redundant, so this patch simplifies the function by removing those
reference parameters.
gdb/ChangeLog
2019-01-10 Tom Tromey <tom@tromey.com>
* xcoffread.c (xcoff_start_psymtab): Remove global_psymbols and
static_psymbols parameters.
(scan_xcoff_symtab): Update.
* psymtab.c (start_psymtab_common): Remove global_psymbols and
static_psymbols parameters.
* psympriv.h (start_psymtab_common): Update.
* mdebugread.c (parse_partial_symbols): Update.
* dwarf2read.c (create_partial_symtab): Update.
* dbxread.c (read_dbx_symtab): Update.
(start_psymtab): Remove global_psymbols and static_psymbols
parameters.
allocate_psymtab has long cleared the new psymtab that is returned.
This patch documents this behavior and then removes some redundant
initializations.
gdb/ChangeLog
2019-01-10 Tom Tromey <tom@tromey.com>
* xcoffread.c (xcoff_end_psymtab): Remove some initializations.
* psymtab.c (allocate_psymtab): Add comment.
* psympriv.h (allocate_psymtab): Add comment.
* dwarf2read.c (dwarf2_create_include_psymtab): Remove some
initializations.
* dbxread.c (dbx_end_psymtab): Remove some initializations.
This commit applies all changes made after running the gdb/copyright.py
script.
Note that one file was flagged by the script, due to an invalid
copyright header
(gdb/unittests/basic_string_view/element_access/char/empty.cc).
As the file was copied from GCC's libstdc++-v3 testsuite, this commit
leaves this file untouched for the time being; a patch to fix the header
was sent to gcc-patches first.
gdb/ChangeLog:
Update copyright year range in all GDB files.
In an earlier patch discussion we noticed that
dwarf2_find_containing_comp_unit takes the address of sect_off, but
doesn't actually need to. This is a leftover from before
C++-ification. This patch simplifies the function.
Tested using gdb.dwarf2 on x86-64 Fedora 28.
gdb/ChangeLog
2018-12-18 Tom Tromey <tom@tromey.com>
* dwarf2read.c (dwarf2_find_containing_comp_unit): Don't take
address of sect_off.
In the dwarf reader we have a set of predicates, these include the
different producer predicates and also some control predicates. The
older ones are declared as integers, while newer ones (added since the
C++ conversion) are bool.
This commit makes them all bool for consistency. There should be no
user visible change after this commit.
gdb/ChangeLog:
* dwarf2read.c (struct dwarf2_cu): Convert the fields 'mark',
'has_loclist', 'checked_producer', 'producer_is_gxx_lt_4_6',
'producer_is_gcc_lt_4_3', 'producer_is_icc_lt_14',
'processing_has_namespace_info' from unsigned int to bool. Update
comments.
(producer_is_icc_lt_14): Update return type.
(producer_is_gcc_lt_4_3): Likewise.
(producer_is_gxx_lt_4_6): Likewise.
(process_die): Write true instead of 1 into predicate fields.
(dwarf2_start_symtab): Likewise.
(var_decode_location): Likewise.
(dwarf2_mark_helper): Likewise.
(dwarf2_mark): Likewise.
(dwarf2_clear_marks): Write false instead of 0 into predicate
field.
(dwarf2_cu::dwarf2_cu): Initialise predicate fields to false, not
0.
Building for x86_64/-m32 with --enable-64-bit-bfd, compilation fails
with:
src/gdb/dwarf2read.c: In instantiation of ‘gdb::array_view<const unsigned char> get_gdb_index_contents_from_section(objfile*, T*) [with T = dwarf2_per_objfile]’:
src/gdb/dwarf2read.c:6266:54: required from here
src/gdb/dwarf2read.c:6192:37: error: narrowing conversion of ‘section->dwarf2_section_info::size’ from ‘bfd_size_type {aka long long unsigned int}’ to ‘size_t {aka unsigned int}’ inside { } [-Werror=narrowing]
return {section->buffer, section->size};
~~~~~~~~~^~~~
This fixes it.
gdb/ChangeLog:
2018-12-07 Pedro Alves <palves@redhat.com>
* dwarf2read.c (get_gdb_index_contents_from_section): Use
gdb::make_array_view.
First of all, I would like to express my gratitude to Keith Seitz, Jan
Kratochvil and Tom Tromey, who were really kind and helped a lot with
this bug. The patch itself was authored by Jan.
This all began with:
https://bugzilla.redhat.com/show_bug.cgi?id=1639242
py-bt is broken, results in exception
In summary, the error reported by the bug above is:
$ gdb -args python3
GNU gdb (GDB) Fedora 8.1.1-3.fc28
(...)
Reading symbols from python3...Reading symbols from /usr/lib/debug/usr/bin/python3.6-3.6.6-1.fc28.x86_64.debug...done.
done.
Dwarf Error: could not find partial DIE containing offset 0x316 [in module /usr/lib/debug/usr/bin/python3.6-3.6.6-1.fc28.x86_64.debug]
After a long investigation, and after thinking that the problem might
actually be on DWZ's side, we were able to determine that there's
something wrong going on when
dwarf2read.c:dwarf2_find_containing_comp_unit performs a binary search
over all of the CUs belonging to an objfile in order to find the CU
which contains a DIE at an specific offset. The current algorithm is:
static struct dwarf2_per_cu_data *
dwarf2_find_containing_comp_unit (sect_offset sect_off,
unsigned int offset_in_dwz,
struct dwarf2_per_objfile *dwarf2_per_objfile)
{
struct dwarf2_per_cu_data *this_cu;
int low, high;
const sect_offset *cu_off;
low = 0;
high = dwarf2_per_objfile->all_comp_units.size () - 1;
while (high > low)
{
struct dwarf2_per_cu_data *mid_cu;
int mid = low + (high - low) / 2;
mid_cu = dwarf2_per_objfile->all_comp_units[mid];
cu_off = &mid_cu->sect_off;
if (mid_cu->is_dwz > offset_in_dwz
|| (mid_cu->is_dwz == offset_in_dwz && *cu_off >= sect_off))
high = mid;
else
low = mid + 1;
}
For the sake of this example, let's consider that "sect_off =
0x7d".
There are a few important things going on here. First,
"dwarf2_per_objfile->all_comp_units ()" will be sorted first by
whether the CU is a DWZ CU, and then by cu->sect_off. In this
specific bug, "offset_in_dwz" is false, which means that, for the most
part of the loop, we're going to do "high = mid" (i.e, we'll work with
the lower part of the vector).
In our particular case, when we reach the part where "mid_cu->is_dwz
== offset_in_dwz" (i.e, both are false), we end up with "high = 2" and
"mid = 1". I.e., there are only 2 elements in the vector who are not
DWZ. The vector looks like this:
#0: cu->sect_off = 0; length = 114; is_dwz = false <-- low
#1: cu->sect_off = 114; length = 7796; is_dwz = false <-- mid
#2: cu->sect_off = 0; length = 28; is_dwz = true <-- high
...
The CU we want is #1, which is exactly where "mid" is. Also, #1 is
not DWZ, which is also exactly what we want. So we perform the second
comparison:
(mid_cu->is_dwz == offset_in_dwz && *cu_off >= sect_off)
^^^^^^^^^^^^^^^^^^^
Because "*cu_off = 114" and "sect_off = 0x7d", this evaluates to
false, so we end up with "low = mid + 1 = 2", which actually gives us
the wrong CU (i.e., a CU that is DWZ). Next in the code, GDB does:
gdb_assert (low == high);
this_cu = dwarf2_per_objfile->all_comp_units[low];
cu_off = &this_cu->sect_off;
if (this_cu->is_dwz != offset_in_dwz || *cu_off > sect_off)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
{
if (low == 0 || this_cu->is_dwz != offset_in_dwz)
error (_("Dwarf Error: could not find partial DIE containing "
"offset %s [in module %s]"),
sect_offset_str (sect_off),
bfd_get_filename (dwarf2_per_objfile->objfile->obfd));
...
Triggering the error we saw in the original bug report.
It's important to notice that we see the error message because the
selected CU is a DWZ one, but we're looking for a non-DWZ CU here.
However, even when the selected CU is *not* a DWZ (and we don't see
any error message), we still end up with the wrong CU. For example,
suppose that the vector had:
#0: cu->sect_off = 0; length = 114; is_dwz = false
#1: cu->sect_off = 114; length = 7796; is_dwz = false
#2: cu->sect_off = 7910; length = 28; is_dwz = false
...
I.e., #2's "is_dwz" is false instead of true. In this case, we still
want #1, because that's where the DIE is located. After the loop ends
up in #2, we have "is_dwz" as false, which is what we wanted, so we
compare offsets. In this case, "7910 >= 0x7d", so we set "mid = high
= 2". Next iteration, we have "mid = 0 + (2 - 0) / 2 = 1", and thus
we examining #1. "is_dwz" is still false, but "114 >= 0x7d" also
evaluates to false, so "low = mid + 1 = 2", which makes the loop stop.
Therefore, we end up choosing #2 as our CU, even though #1 is the
right one.
The problem here is happening because we're comparing "sect_off"
directly against "*cu_off", while we should actually be comparing
against "*cu_off + mid_cu->length" (i.e., the end offset):
...
|| (mid_cu->is_dwz == offset_in_dwz
&& *cu_off + mid_cu->length >= sect_off))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
And this is what the patch does. The idea is that if GDB is searching
for an offset that falls above the *end* of the CU being
analyzed (i.e., "mid"), then the next iteration should try a
higher-offset CU next. The previous algorithm was using
the *beginning* of the CU.
Unfortunately, I could not devise a testcase for this problem, so I am
proposing a fix with this huge explanation attached to it in the hope
that it is sufficient. After talking a bit to Keith (our testcase
guru), it seems that one would have to create an objfile with both DWZ
and non-DWZ sections, which may prove very hard to do, I think.
I ran this patch on our BuildBot, and no regressions were detected.
gdb/ChangeLog:
2018-11-30 Jan Kratochvil <jan.kratochvil@redhat.com>
Keith Seitz <keiths@redhat.com>
Tom Tromey <tom@tromey.com>
Sergio Durigan Junior <sergiodj@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1613614
* dwarf2read.c (dwarf2_find_containing_comp_unit): Add
'mid_cu->length' to '*cu_off' when checking if 'sect_off' is
inside the CU.
In this commit:
commit eb77c9df9f
Date: Thu Oct 18 14:04:27 2018 +0100
gdb: Handle ICC's unexpected void return type
A potential dereference of a NULL pointer was introduced if a
DW_TAG_base_type is missing a DW_AT_name attribute.
I have taken this opportunity to fix a slight confusion that existed
in the test also added in the above commit, the test had two C
variables, declared like this:
int var_a = 5;
void *var_ptr = &var_a;
However, the fake DWARF in the test script declared them like this:
void var_a = 5;
void *var_ptr = &var_a;
This wasn't a problem as the test never uses 'var_a' directly, this
only exists so 'var_ptr' can be initialised. However, it seemed worth
fixing.
I've also added a test for a DW_TAG_base_type with a missing
DW_AT_name, as clearly there's not test currently that covers this
(the original patch tested cleanly). I can confirm that the new test
causes GDB to crash before this patch, and passes with this patch.
gdb/ChangeLog:
* dwarf2read.c (dwarf2_init_integer_type): Check for name being
NULL before dereferencing it.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/void-type.exp: Rename types, and make var_a an 'int'.
* gdb.dwarf2/missing-type-name.exp: New file.
I encountered a binary compiled with Intel's C Compiler (ICC) version
14.0.5.212, which seemed to contain some non-standard DWARF.
The DWARF spec (V5 3.3.2) says:
Debugging information entries for C void functions should not have
an attribute for the return type.
However, what I observed in the DWARF from this ICC compiled binary
was this:
...
<0><857>: Abbrev Number: 1 (DW_TAG_compile_unit)
<858> DW_AT_comp_dir : (indirect string, offset: 0x48d): /tmp/
<85c> DW_AT_language : 1 (ANSI C)
<85d> DW_AT_name : (indirect string, offset: 0x77c): filename.c
<861> DW_AT_producer : (indirect string, offset: 0x520): Intel(R) C Intel(R) 64 Compiler ...
<865> DW_AT_low_pc : 0x4378d0
<86d> DW_AT_high_pc : 0x4378f0
<875> DW_AT_stmt_list : 0xa37
...
<1><7ea>: Abbrev Number: 2 (DW_TAG_base_type)
<7eb> DW_AT_byte_size : 0
<7ec> DW_AT_encoding : 5 (signed)
<7ed> DW_AT_name : (indirect string, offset: 0x58f): void
...
<1><7f1>: Abbrev Number: 3 (DW_TAG_subprogram)
<7f2> DW_AT_decl_line : 268
<7f4> DW_AT_decl_column : 30
<7f5> DW_AT_decl_file : 1
<7f6> DW_AT_type : <0x7ea>
<7fa> DW_AT_prototyped : 1
<7fb> DW_AT_name : (indirect string, offset: 0x761): function_foo
<7ff> DW_AT_MIPS_linkage_name: (indirect string, offset: 0x761): function_foo
<803> DW_AT_low_pc : 0x4378a0
<80b> DW_AT_high_pc : 0x4378d0
<813> DW_AT_external : 1
...
So function 'function_foo' has void return type, but still has a
DW_AT_type attribute for a 0 sized type called void.
What was found was that when the 'finish' command was used to leave
'function_foo', GDB would crash.
The problem is that in infcmd.c:print_return_value GDB tries to filter
out void return types, by looking for the TYPE_CODE_VOID, this fails
for the 'void' type as it has code TYPE_CODE_INT and GDB then tries to
print the 'void' type.
This eventually ends in a call to valprint.c:maybe_negate_by_bytes,
however, the len (length) of the value being negated is 0, which is
not detected or expected by this code, and invalid memory accesses
occur, some of which might cause GDB to crash.
The above DWARF was seen on version 14.0.5.212 of ICC.
I have also tested ICC versions 18.0.2.199 and 17.0.7.259, on both of
these versions, the DW_AT_type on the DW_TAG_subprogram has been
removed, bringing ICC inline with the DWARF standard, and with the
DWARF produced by GCC.
I only have limited access to these specific versions of ICC so I am
unable to get more specific details for when the generated DWARF
became non-standard or when it was changed to be more inline with the
DWARF standard.
Further testing revealed additional places where ICC produced 'void'
related DWARF that GDB struggles with. When I compiled code that
contained a function with this signature:
void funcx (void *arg);
on ICC 17/18, I got the following DWARF (notice the void return type
is now gone):
...
<1><32>: Abbrev Number: 2 (DW_TAG_subprogram)
<33> DW_AT_decl_line : 2
<34> DW_AT_decl_file : 1
<35> DW_AT_prototyped : 1
<36> DW_AT_name : (indirect string, offset: 0xc5): funcx
<3a> DW_AT_MIPS_linkage_name: (indirect string, offset: 0xc5): funcx
<3e> DW_AT_low_pc : 0x6dc
<46> DW_AT_high_pc : 0x703
<4e> DW_AT_external : 1
<2><4f>: Abbrev Number: 3 (DW_TAG_formal_parameter)
<50> DW_AT_decl_line : 2
<51> DW_AT_decl_file : 1
<52> DW_AT_type : <0x6a>
<56> DW_AT_name : arg
<5a> DW_AT_location : 2 byte block: 76 70 (DW_OP_breg6 (rbp): -16)
...
<1><6a>: Abbrev Number: 5 (DW_TAG_pointer_type)
<6b> DW_AT_type : <0x6f>
<1><6f>: Abbrev Number: 6 (DW_TAG_base_type)
<70> DW_AT_byte_size : 0
<71> DW_AT_encoding : 5 (signed)
<72> DW_AT_name : (indirect string, offset: 0xcb): void
...
However, the function argument 'arg' does still reference a 'void'
type. This case doesn't seem as obviously non-standard as the
previous one, but I think that the DWARF standard (V5 5.2) does
suggest that the above is not the recommended approach. If we compare
to the DWARF generated by GCC 7.3.1:
...
<1><68>: Abbrev Number: 5 (DW_TAG_subprogram)
<69> DW_AT_external : 1
<69> DW_AT_name : (indirect string, offset: 0x221): funcx
<6d> DW_AT_decl_file : 1
<6e> DW_AT_decl_line : 2
<6f> DW_AT_prototyped : 1
<6f> DW_AT_low_pc : 0x400487
<77> DW_AT_high_pc : 0x22
<7f> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
<81> DW_AT_GNU_all_call_sites: 1
<81> DW_AT_sibling : <0xa0>
<2><85>: Abbrev Number: 6 (DW_TAG_formal_parameter)
<86> DW_AT_name : arg
<8a> DW_AT_decl_file : 1
<8b> DW_AT_decl_line : 2
<8c> DW_AT_type : <0xa0>
<90> DW_AT_location : 2 byte block: 91 58 (DW_OP_fbreg: -40)
...
<1><a0>: Abbrev Number: 7 (DW_TAG_pointer_type)
<a1> DW_AT_byte_size : 8
...
Here we see that the DW_TAG_pointer_type doesn't reference any further
type. This also seems out of line with the DWARF standard (which I
think recommends using a DW_TAG_unspecified_type entry), however GDB
does handle the GCC generated DWARF better.
If we look at how GDB handles the DWARF from GCC, then we see this:
(gdb) print *arg
Attempt to dereference a generic pointer.
While on the current HEAD of master dereferencing arg causes undefined
behaviour which will likely crash GDB (for the same reason as was
described above for the 'finish' case). On earlier versions of GDB
the ICC DWARF would cause this:
(gdb) print *arg
$1 = 0
In this patch both the return type, and general variable/parameter
type handling is fixed by transforming the synthetic void entries in
the DWARF, the ones that look like this:
<1><6f>: Abbrev Number: 6 (DW_TAG_base_type)
<70> DW_AT_byte_size : 0
<71> DW_AT_encoding : 5 (signed)
<72> DW_AT_name : (indirect string, offset: 0xcb): void
into GDB's builtin void type. My criteria for performing the fix are:
1. Binary produced by any version of ICC,
2. We're producing an integer type,
3. The size is 0, and
4. The name is "void".
I ignore the signed / unsigned nature of the integer.
Potentially we could drop the ICC detection too, this should be a
reasonably safe transformation to perform, however, I'm generally
pretty nervous when it comes to modifying how the DWARF is parsed so,
for now, I have restricted this to ICC only.
I also added an assertion to maybe_negate_by_bytes. This is nothing
to do with the actual fix, but should detect incorrect use of this
function in the future, without relying on undefined behaviour to
crash GDB.
I added a new test that makes use the of the testsuite's DWARF
generator. As it is tricky to create target independent tests that
pass function parameters using the DWARF generator (as specifying the
argument location is target specific) I have instead made use of a
global variable void*. This still shows the issue.
We already have a predicate in the DWARF parser to detect versions of
ICC prior to 14, however, this issue was spotted on a later version.
As a result I've added a new predicate that is true for any version of
ICC.
gdb/ChangeLog:
* dwarf2read.c (struct dwarf2_cu): Add producer_is_icc field.
(producer_is_icc): New function.
(check_producer): Set producer_is_icc field on dwarf2_cu.
(dwarf2_init_integer_type): New function.
(read_base_type): Call dwarf2_init_integer_type instead of
init_integer_type in all cases.
(dwarf2_cu::dwarf2_cu): Initialise producer_is_icc field.
* valprint.c (maybe_negate_by_bytes): Add an assertion that the
LEN is greater than 0.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/void-type.c: New file.
* gdb.dwarf2/void-type.exp: New file.
This removes a couple of DEF_VECs from symtab.h, replacing them with
std::vector at the points of use.
gdb/ChangeLog
2018-10-26 Tom Tromey <tom@tromey.com>
* dwarf2read.c (recursively_compute_inclusions): Use std::vector.
(compute_compunit_symtab_includes): Update.
* symtab.h: (symtab_ptr): Remove typedef. Don't define a VEC.
(compunit_symtab_ptr): Likewise.
This commit fixes a buffer overrun found by Coverity, where
36 bytes are written into a 24 byte buffer.
gdb/ChangeLog:
* dwarf2read.c (create_dwp_hash_table): Fix buffer overrun
found by Coverity.
gdb/ChangeLog:
* dwarf2read.c (dwarf2_cu) <producer_is_codewarrior>: New field.
(check_producer): Check if the producer is codewarrior.
(producer_is_codewarrior): New function.
(lnp_state_machine::record_line): Ignore is_stmt flag for records
produced by codewarrior.
(dwarf2_cu::dwarf2_cu): Initialize producer_is_codewarrior.
This fixes all the straightforward -Wshadow=local warnings in gdb. A
few standard approaches are used here:
* Renaming an inner (or outer, but more commonly inner) variable;
* Lowering a declaration to avoid a clash;
* Moving a declaration into a more inner scope to avoid a clash,
including the special case of moving a declaration into a loop header.
I did not consider any of the changes in this patch to be particularly
noteworthy, though of course they should all still be examined.
gdb/ChangeLog
2018-10-04 Tom Tromey <tom@tromey.com>
* ctf.c (SET_ARRAY_FIELD): Rename "u32".
* p-valprint.c (pascal_val_print): Split inner "i" variable.
* xtensa-tdep.c (xtensa_push_dummy_call): Declare "i" in loop
header.
* xstormy16-tdep.c (xstormy16_push_dummy_call): Declare "val" in
more inner scope.
* xcoffread.c (read_xcoff_symtab): Rename inner "symbol".
* varobj.c (varobj_update): Rename inner "newobj",
"type_changed".
* valprint.c (generic_emit_char): Rename inner "buf".
* valops.c (find_overload_match): Rename inner "temp".
(value_struct_elt_for_reference): Declare "v" in more inner
scope.
* v850-tdep.c (v850_push_dummy_call): Rename "len".
* unittests/array-view-selftests.c (run_tests): Rename inner
"vec".
* tui/tui-stack.c (tui_show_frame_info): Declare "i" in loop
header.
* tracepoint.c (merge_uploaded_trace_state_variables): Declare
"tsv" in more inner scope.
(print_one_static_tracepoint_marker): Rename inner
"tuple_emitter".
* tic6x-tdep.c (tic6x_analyze_prologue): Declare "inst" lower.
(tic6x_push_dummy_call): Don't redeclare "addr".
* target-float.c: Declare "dto" lower.
* symtab.c (lookup_local_symbol): Rename inner "sym".
(find_pc_sect_line): Rename inner "pc".
* stack.c (print_frame): Don't redeclare "gdbarch".
(return_command): Rename inner "gdbarch".
* s390-tdep.c (s390_prologue_frame_unwind_cache): Renam inner
"sp".
* rust-lang.c (rust_internal_print_type): Declare "i" in loop
header.
* rs6000-tdep.c (ppc_process_record): Rename inner "addr".
* riscv-tdep.c (riscv_push_dummy_call): Declare "info" in inner
scope.
* remote.c (remote_target::update_thread_list): Don't redeclare
"tp".
(remote_target::process_initial_stop_replies): Rename inner
"thread".
(remote_target::remote_parse_stop_reply): Don't redeclare "p".
(remote_target::wait_as): Don't redeclare "stop_reply".
(remote_target::get_thread_local_address): Rename inner
"result".
(remote_target::get_tib_address): Likewise.
I get the following error with gcc 6.3.0:
/home/simark/src/binutils-gdb/gdb/dwarf2read.c: In function 'void read_func_scope(die_info*, dwarf2_cu*)':
/home/simark/src/binutils-gdb/gdb/dwarf2read.c:13838:12: error: types may not be defined in a for-range-declaration [-Werror]
for (struct symbol *sym : template_args)
^~~~~~
Removing the struct keyword fixes it.
gdb/ChangeLog:
* dwarf2read.c (read_func_scope): Remove struct keyword in
range-based for.
Tom de Vries