The debugging code in linux-waitpid.c is one of the few remaining
spots that depends on the gdb/gdbserver difference.
My first thought was that this code is not extremely useful, so this
patch removes this code. (However, if it is actually useful to
someone, we could make it work by introducing a new abstraction.)
gdb/ChangeLog
2019-06-11 Tom Tromey <tom@tromey.com>
* nat/linux-waitpid.c: Don't include server.h.
(linux_debug): Remove.
(my_waitpid): Update.
I noticed recently that some command had a trailing newline in its
"help" output. So, I temporarily hacked cli-decode.c to print
something when a new command was installed that had a trailing newline
in its help message, and wrote this patch, which removes all the ones
I could find this way. (There could still be a few more in *-nat
files.)
Tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-06-11 Tom Tromey <tromey@adacore.com>
* infcall.c (_initialize_infcall): Remove trailing newline from
help.
* user-regs.c (_initialize_user_regs): Remove trailing newline
from help.
* typeprint.c (_initialize_typeprint): Remove trailing newline
from help.
* reverse.c (_initialize_reverse): Remove trailing newlines from
help.
* tracepoint.c (_initialize_tracepoint): Remove trailing newlines
from help.
* language.c (add_set_language_command): Remove trailing newline
from help.
* infcmd.c (_initialize_infcmd): Remove trailing newlines from
help.
* disasm.c (_initialize_disasm): Remove trailing newline from
help.
* top.c (init_main): Remove trailing newline from help.
* interps.c (_initialize_interpreter): Remove trailing newline
from help.
* btrace.c (_initialize_btrace): Remove trailing newlines from
help.
* breakpoint.c (_initialize_breakpoint): Remove trailing newline
from help.
* python/python.c (_initialize_python): Remove trailing newline
from help.
* spu-tdep.c (_initialize_spu_tdep): Remove trailing newlines from
help.
* tui/tui-win.c (_initialize_tui_win): Remove trailing newlines
from help. Reformat some text.
* tui/tui-stack.c (_initialize_tui_stack): Remove trailing newline
from help.
* tui/tui-layout.c (_initialize_tui_layout): Remove trailing
newline from help.
We see this failure with the readnow board:
...
FAIL: gdb.multi/remove-inferiors.exp: load binary
...
When running with board readnow, an extra message "Expanding full symbols" is
emitted after the "Reading symbols" message, and the regexp corresponding to
the FAIL only allows the first message.
Fix this by allowing the extra message in the regexp.
gdb/testsuite/ChangeLog:
2019-06-11 Tom de Vries <tdevries@suse.de>
PR testsuite/24521
* gdb.multi/remove-inferiors.exp: Allow "Expanding full symbols"
message.
Building on Darwin with gcc showed that darwin-nat.c had some
shadowing variable declarations. This removes them.
gdb/ChangeLog
2019-06-11 Tom Tromey <tromey@adacore.com>
* darwin-nat.c (darwin_decode_exception_message)
(darwin_decode_message, darwin_nat_target::kill): Fix shadowing.
When running gdb.dwarf2/nonvar-access.exp with board readnow, we have:
...
FAIL: gdb.dwarf2/nonvar-access.exp: print/x def_implicit_s
...
and 12 more similar failures.
I've tracked this down to the range of main being hardcoded to
[_main, _main+0x10000) in the dwarf assembly:
...
DW_TAG_subprogram {
{name main}
{DW_AT_external 1 flag}
{low_pc [gdb_target_symbol main] DW_FORM_addr}
{high_pc [gdb_target_symbol main]+0x10000 DW_FORM_addr}
} {
...
which overlaps with the .debug_info for the elf-init.c CU (containing
__libc_csu_init and __libc_csu_fini).
Fix this by using function_range to find the actual range of main.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-06-11 Tom de Vries <tdevries@suse.de>
PR testsuite/24521
* gdb.dwarf2/nonvar-access.exp: Fix main high_pc.
When extracting an array slice we should give up if the array is
not-allocated or not-associated. For Fortran, at least in gfortran
compiled code, the upper and lower bounds are undefined if the array
is not allocated or not associated, in which case performing checks
against these bounds will result in undefined behaviour.
Better then to throw an error if we try to slice such an array. This
changes the error message that the user will receive in these
cases (if they got an error message before). Previously they may have
gotten "slice out of range" now they'll get "array not allocated" or
"array not associated".
gdb/ChangeLog:
* valops.c (value_slice): Check for not allocated or not
associated values.
gdb/testsuite/ChangeLog:
* gdb.fortran/vla-sizeof.exp: Update expected results.
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.
When compiling gdb with '-lasan -fsanitizer=address' and running tests with
'export ASAN_OPTIONS="detect_leaks=0:alloc_dealloc_mismatch=0"', I run into:
...
ERROR: GDB process no longer exists
UNRESOLVED: gdb.linespec/cpls-abi-tag.exp: \
test_abi_tag: completion: at tag: tab complete "b test_abi_tag_function[abi:"
...
In more detail:
...
==3637==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on address \
0x7fff5952bbdd at pc 0x000000fe5c57 bp 0x7fff5952af30 sp 0x7fff5952af28
READ of size 1 at 0x7fff5952bbdd thread T0
#0 0xfe5c56 in linespec_lexer_lex_string src/gdb/linespec.c:727
#1 0xfe7473 in linespec_lexer_lex_one src/gdb/linespec.c:946
#2 0xfe799d in linespec_lexer_consume_token src/gdb/linespec.c:982
#3 0xff446d in parse_linespec src/gdb/linespec.c:2564
#4 0xff78be in linespec_complete(completion_tracker&, char const*, \
symbol_name_match_type) src/gdb/linespec.c:2961
#5 0xb9299c in complete_address_and_linespec_locations \
src/gdb/completer.c:573
#6 0xb93e90 in location_completer(cmd_list_element*, completion_tracker&, \
char const*, char const*) src/gdb/completer.c:919
#7 0xb940c5 in location_completer_handle_brkchars src/gdb/completer.c:956
#8 0xb957ec in complete_line_internal_normal_command \
src/gdb/completer.c:1208
#9 0xb96507 in complete_line_internal_1 src/gdb/completer.c:1430
#10 0xb965c2 in complete_line_internal src/gdb/completer.c:1449
#11 0xb98630 in gdb_completion_word_break_characters_throw \
src/gdb/completer.c:1862
#12 0xb98838 in gdb_completion_word_break_characters() \
src/gdb/completer.c:1897
#13 0x16c6362 in _rl_find_completion_word src/readline/complete.c:943
#14 0x16ca8d0 in rl_complete_internal src/readline/complete.c:1843
#15 0x16c460c in rl_complete src/readline/complete.c:408
#16 0x16b3368 in _rl_dispatch_subseq src/readline/readline.c:774
#17 0x16b3092 in _rl_dispatch src/readline/readline.c:724
#18 0x16b2939 in readline_internal_char src/readline/readline.c:552
#19 0x16f1fb0 in rl_callback_read_char src/readline/callback.c:201
#20 0xddc5a1 in gdb_rl_callback_read_char_wrapper_noexcept \
src/gdb/event-top.c:175
#21 0xddc773 in gdb_rl_callback_read_char_wrapper src/gdb/event-top.c:192
#22 0xddd9f5 in stdin_event_handler(int, void*) src/gdb/event-top.c:514
#23 0xdd7d8f in handle_file_event src/gdb/event-loop.c:731
#24 0xdd8607 in gdb_wait_for_event src/gdb/event-loop.c:857
#25 0xdd629c in gdb_do_one_event() src/gdb/event-loop.c:321
#26 0xdd6344 in start_event_loop() src/gdb/event-loop.c:370
#27 0x10a7715 in captured_command_loop src/gdb/main.c:331
#28 0x10aa548 in captured_main src/gdb/main.c:1173
#29 0x10aa5d8 in gdb_main(captured_main_args*) src/gdb/main.c:1188
#30 0x87bd35 in main src/gdb/gdb.c:32
#31 0x7fb0364c6f89 in __libc_start_main (/lib64/libc.so.6+0x20f89)
#32 0x87bb49 in _start (build/gdb/gdb+0x87bb49)
Address 0x7fff5952bbdd is located in stack of thread T0 at offset 557 in frame
#0 0xb93702 in location_completer(cmd_list_element*, completion_tracker&, \
char const*, char const*) src/gdb/completer.c:831
This frame has 4 object(s):
[32, 40) 'copy'
[96, 104) 'location'
[160, 168) 'text'
[224, 256) 'completion_info' <== Memory access at offset 557 overflows \
this variable
HINT: this may be a false positive if your program uses some custom stack \
unwind mechanism or swapcontext
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: dynamic-stack-buffer-overflow \
src/gdb/linespec.c:727 in linespec_lexer_lex_string
Shadow bytes around the buggy address:
0x10006b29d720: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10006b29d730: 00 00 00 00 00 00 f1 f1 f1 f1 00 f2 f2 f2 f2 f2
0x10006b29d740: f2 f2 00 f2 f2 f2 f2 f2 f2 f2 00 f2 f2 f2 f2 f2
0x10006b29d750: f2 f2 00 00 00 00 f3 f3 f3 f3 00 00 00 00 00 00
0x10006b29d760: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x10006b29d770: 00 00 00 00 ca ca ca ca 00 00 00[05]cb cb cb cb
0x10006b29d780: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
0x10006b29d790: 00 f2 f2 f2 f2 f2 f2 f2 00 f2 f2 f2 f3 f3 f3 f3
0x10006b29d7a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10006b29d7b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10006b29d7c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
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
==3637==ABORTING
...
The problem happens in linespec_lexer_lex_string when lexing
"b test_abi_tag_function[abi:\0" (using a notation where we make the implicit
terminating \0 explicit).
We arrrive here with (PARSER_STREAM (parser)) == ":\0":
...
/* Do not tokenize ABI tags such as "[abi:cxx11]". */
else if (PARSER_STREAM (parser) - start > 4
&& startswith (PARSER_STREAM (parser) - 4, "[abi"))
++(PARSER_STREAM (parser));
...
and consume ':', after which we end up here and consume '\0':
...
/* Advance the stream. */
++(PARSER_STREAM (parser));
...
after which (PARSER_STREAM (parser)) points past the end of the string.
Fix this by removing the first "++(PARSER_STREAM (parser))", and add an assert
to the second one to detect moving past the end-of-string.
Build and tested on x86_64-linux.
gdb/ChangeLog:
2019-06-10 Tom de Vries <tdevries@suse.de>
PR gdb/24611
* linespec.c (linespec_lexer_lex_string): Remove incorrect
"++(PARSER_STREAM (parser))" for "[abi"-prefixed colon. Add assert.
The commit "[gdb/symtab] Fix language of duplicate static minimal symbol"
introduces a performance regression, when loading a cc1 executable build with
-O0 -g and gcc 7.4.0. The performance regression, measured in 'real' time is
about 175%.
The slower execution comes from the fact that the fix in symbol_set_names
makes the call to symbol_find_demangled_name unconditional.
Fix this by reverting the commit, and redoing the fix as follows.
Recapturing the original problem, the first time symbol_set_names is called
with gsymbol.language == lang_auto and linkage_name == "_ZL3foov", the name is
not present in the per_bfd->demangled_names_hash hash table, so
symbol_find_demangled_name is called to demangle the name, after which the
mangled/demangled pair is added to the hashtable. The call to
symbol_find_demangled_name also sets gsymbol.language to lang_cplus.
The second time symbol_set_names is called with gsymbol.language == lang_auto
and linkage_name == "_ZL3foov", the name is present in the hash table, so the
demangled name from the hash table is used. However, the language of the
symbol remains lang_auto.
Fix this by adding a field language in struct demangled_name_entry, and using
the field in symbol_set_names to set the language of gsymbol, if necessary.
Tested on x86_64-linux.
gdb/ChangeLog:
2019-06-10 Tom de Vries <tdevries@suse.de>
PR symtab/24545
* symtab.c (struct demangled_name_entry): Add language field.
(symbol_set_names): Revert "[gdb/symtab] Fix language of duplicate
static minimal symbol". Set and use language field.
I noticed that the "catch assert" help text erroneously claimed to
accept an argument, and while fixing this I went ahead and added
"Usage" text and made other minor updates to the commands in
ada-lang.c.
Tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-06-10 Tom Tromey <tromey@adacore.com>
* ada-lang.c (_initialize_ada_language): Update help text.
ARI pointed out that a recent patch introduced a call to "warning"
with a string that ended in a newline:
https://sourceware.org/ml/gdb-patches/2019-06/msg00000.html
This is generally forbidden, I believe, because warning adds its own
newline.
This patch removes all of the trailing newlines I was able to find. I
searched for 'warning (.*\\n"' and then fixed the ones where the
newline appeared at the end of the string (some had internal
newlines).
Tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-06-10 Tom Tromey <tromey@adacore.com>
* m32c-tdep.c (m32c_m16c_address_to_pointer): Don't end warning
with a newline.
* guile/guile.c (handle_boot_error): Don't end warning with a
newline.
* cli/cli-cmds.c (exit_status_set_internal_vars): Don't end
warning with a newline.
* s12z-tdep.c (s12z_skip_prologue): Don't end warning with a
newline.
(s12z_frame_cache): Likewise.
* dwarf-index-cache.c (index_cache::store): Don't end warning with
a newline.
* solib-svr4.c (disable_probes_interface): Don't end warning with
a newline.
* nat/fork-inferior.c (fork_inferior): Don't end warning with a
newline.
* python/python.c (do_finish_initialization): Don't end warning
with a newline.
gdb/gdbserver/ChangeLog
2019-06-10 Tom Tromey <tromey@adacore.com>
* remote-utils.c (look_up_one_symbol, relocate_instruction): Don't
end warning with a newline.
* linux-s390-low.c (s390_get_wordsize): Don't end warning with a
newline.
* thread-db.c (attach_thread): Don't end warning with a newline.
(thread_db_notice_clone): Likewise.
* tracepoint.c (gdb_agent_helper_thread): Don't end warning with a
newline.
* linux-x86-low.c (x86_get_min_fast_tracepoint_insn_len): Don't
end warning with a newline.
A few spots in py-breakpoint.c acquire the GIL manually. However,
because these spots generate events, and because events are expected
to be arbitrary gdb-flavored Python code, it's important to use
gdbpy_enter instead, in order to ensure that the other gdb-related
Python globals are set correctly.
This patch makes this change. Tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-06-10 Tom Tromey <tom@tromey.com>
* python/py-breakpoint.c (gdbpy_breakpoint_created)
(gdbpy_breakpoint_deleted, gdbpy_breakpoint_modified): Use
gdbpy_enter.
I noticed that elfread.c always allocates a dbx_symfile_info, even
though this is only ever needed in the unusual case of reading stabs
in ELF.
This patch moves the allocation into dbxread.c, and applies the same
treatment to similar code in coffread.c.
Regression tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-06-10 Tom Tromey <tromey@adacore.com>
* elfread.c (elf_read_minimal_symbols): Don't set the dbx objfile
data.
(elf_new_init): Don't call stabsread_new_init.
* dbxread.c (coffstab_build_psymtabs): Set dbx objfile data.
(elfstab_build_psymtabs): Likewise. Call stabsread_new_init.
* coffread.c (coff_symfile_init): Don't set the dbx objfile data.
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.
When source file path is relative to the build directory (which
is considered a good practice and is enforced in certain buildsystems,
such as meson), gdb only applies substitute-path to the build directory
path. Then gdb appends the source file path to the rewritten build
directory path, and tries to access that.
This fails if either two of the following conditions are true:
a) The user didn't specify substitute-path for the build directory.
This is highly likely, since path substitution for build directories
is not documented anywhere, and since gdb does not tell[0] the user
the path to the build directory, just the source file path.
b) The source file path changed.
This can also easily happen, since a source path that is relative
to the build directory can include any number of directory names
that are not part of the program source tree (starting with the
name of the root directory of the source tree). Gdb will not apply
substitute-path to that relative path, thus there is no way for
the user to tell gdb about these changes.
This commit changes the code to apply substitute-path to all filenames,
both relative and absolute. This way it is possible to do things like:
set substitute-path ../foobar-1.0 /src/my/foobar-1.0
which is completely in line with the user expectations.
This might break unusual cases where build directory path is also
relative (is that even possible?) and happens to match the path
to the source directory (i.e. happens to match a substitution rule).
[0]: There's a "maintenance info symtabs" command that does show the names
of the build directories, but normal users are not required to
know or use that.
gdb/ChangeLog
2019-06-06 Руслан Ижбулатов <lrn1986@gmail.com>
* source.c (find_and_open_source): Also rewrite relative file
names.
Currently "maint time" will print the amount of time a command took.
Sometimes, though, it's useful to have a timestamp as well -- for
example if one is correlating a gdb log with some other log.
This patch adds a timestamp to the start and end of each command when
this setting is in effect.
This also removes a "//" comment and changes scoped_command_stats to
use DISABLE_COPY_AND_ASSIGN; two minor things I noticed while working
on the patch.
Tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-06-06 Tom Tromey <tromey@adacore.com>
* maint.h (class scoped_command_stats): Use
DISABLE_COPY_AND_ASSIGN.
<print_time>: New method.
* maint.c (scoped_command_stats, ~scoped_command_stats): Call
print_time.
(scoped_command_stats::print_time): New method.
gdb/testsuite/ChangeLog
2019-06-06 Tom Tromey <tromey@adacore.com>
* gdb.base/maint.exp: Expect command started/finished output.
Remove the use of 'I' within some comments in a recently added test.
gdb/testsuite/ChangeLog:
* gdb.arch/riscv-unwind-long-insn-6.s: Remove use of 'I' in
comment.
* gdb.arch/riscv-unwind-long-insn-8.s: Likewise.
If the RISC-V prologue scanner finds a 6 or 8 byte instruction we
currently throw an internal error, which is not great for the user.
A mechanism already exists in the prologue scanner to leave
instructions marked as unknown so that we can stop the prologue scan
without raising an error, this is used for all 2 and 4 byte
instructions that are not part of the small set the prologue scanner
actually understands.
This commit changes GDB so that all 6 and 8 byte instructions are
marked as unknown, rather than causing an error.
gdb/ChangeLog:
* riscv-tdep.c (riscv_insn::decode): Gracefully ignore
instructions of lengths 6 or 8 bytes.
gdb/testsuite/ChangeLog:
* gdb.arch/riscv-unwind-long-insn-6.s: New file.
* gdb.arch/riscv-unwind-long-insn-8.s: New file.
* gdb.arch/riscv-unwind-long-insn.c: New file.
* gdb.arch/riscv-unwind-long-insn.exp: New file.
Adds an utility function to make it shorter to write the common case
of wrapping an xstrdup with a unique_xmalloc_ptr, and uses it
throughout.
Note: I tried to put this in common/common-utils.h near skip_spaces,
etc. but that is included in common/common-defs.h before
common/gdb_unique_ptr.h is included, so it would fail to compile
because gdb::unique_xmalloc_ptr isn't defined at that point yet. I
tried moving the gdb_unique_ptr.h inclusion before common-utils.h, but
that doesn't work because gdb_unique_ptr.h depends on common-utils.h
for xfree.
gdb/ChangeLog:
2019-06-04 Pedro Alves <palves@redhat.com>
* common/gdb_unique_ptr.h (make_unique_xstrdup): New.
* ada-lang.c (catch_ada_completer): Use make_unique_xstrdup.
* breakpoint.c (condition_completer): Likewise.
* cli/cli-dump.c (scan_expression): Likewise.
* common/filestuff.c (mkdir_recursive): Likewise.
* common/gdb_tilde_expand.c (gdb_tilde_expand_up)
* common/pathstuff.c (gdb_realpath, gdb_realpath_keepfile)
(gdb_abspath): Likewise.
* compile/compile-cplus-types.c
(compile_cplus_instance::decl_name): Likewise.
* completer.c (complete_explicit_location):
(signal_completer, reg_or_group_completer_1): Likewise.
* cp-support.c (cp_remove_params_if_any): Likewise.
* fbsd-tdep.c (fbsd_core_vnode_path): Likewise.
* guile/scm-safe-call.c (gdbscm_safe_eval_string): Likewise.
* infcmd.c (strip_bg_char): Likewise.
* linespec.c (copy_token_string): Likewise.
* mi/mi-main.c (output_cores): Likewise.
* psymtab.c (psymtab_search_name):
* symfile.c (test_set_ext_lang_command): Likewise.
* target.c (target_fileio_read_stralloc): Likewise.
* tui/tui-regs.c (tui_reggroup_completer): Likewise.
* value.c (complete_internalvar): Likewise.
gdb/gdbserver/ChangeLog:
2019-06-04 Pedro Alves <palves@redhat.com>
* server.c (captured_main): Use make_unique_xstrdup.
This allows users of the Python API to find the objfile where a type
was defined.
gdb/ChangeLog:
gdb/ChangeLog
2019-06-04 Christian Biesinger <cbiesinger@google.com>
Add objfile property to gdb.Type.
* gdb/NEWS: Mention Python API addition.
* gdb/python/py-type.c (typy_get_objfile): New method.
gdb/doc/ChangeLog
2019-06-04 Christian Biesinger <cbiesinger@google.com>
* gdb/doc/python.texi: Document new gdb.Type.objfile property.
gdb/testsuite/ChangeLog
2019-06-04 Christian Biesinger <cbiesinger@google.com>
* gdb/testsuite/gdb.python/py-type.exp: Test for new
gdb.Type.objfile property.
The "help" command can output long list of command names or classes.
Use the title style to style the command names or classes to make
the output more readable.
Similarly, change "apropos" command to also style the command names.
It is sometimes unclear why "apropos REGEXP" lists some commands,
and then the user has to manually do 'help command' for all commands
listed by "apropos" to see more details about the matching commands.
=> Add an optional flag -v so that "apropos -v REGEXP":
* outputs the full documentation of matching commands.
* highlights the documentation parts matching REGEXP.
Have 'show style' and its subcommands using a style to style its output.
This allows the GDB user or developer to use 'show style' to visually see
with one command how all the current styles look like.
Add 2 new styles highlight style, title style and fputs_highlighted function.
Highlight style is used by fputs_highlighted to highlight the parts of
its char *STR argument that match a HIGHLIGHT regexp.
This (and the title style) will be used in a following patch.
gdbreplay had its own implementation of fromhex. This patch changes
it to use the one in common/.
gdb/gdbserver/ChangeLog
2019-06-02 Tom Tromey <tom@tromey.com>
* gdbreplay.c (fromhex): Remove.
* Makefile.in (GDBREPLAY_OBS): Add rsp-low.o.
gdb/testsuite/ChangeLog
2019-05-31 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.base/shell.exp: Test pipe command, $_shell_exitcode,
$_shell_exitsignal.
* gdb.base/default.exp: Update for new convenience variables.
The pipe command allows to run a GDB command, and pipe its output
to a shell command:
(gdb) help pipe
Send the output of a gdb command to a shell command.
Usage: | [COMMAND] | SHELL_COMMAND
Usage: | -d DELIM COMMAND DELIM SHELL_COMMAND
Usage: pipe [COMMAND] | SHELL_COMMAND
Usage: pipe -d DELIM COMMAND DELIM SHELL_COMMAND
Executes COMMAND and sends its output to SHELL_COMMAND.
The -d option indicates to use the string DELIM to separate COMMAND
from SHELL_COMMAND, in alternative to |. This is useful in
case COMMAND contains a | character.
With no COMMAND, repeat the last executed command
and send its output to SHELL_COMMAND.
(gdb)
For example:
(gdb) pipe print some_data_structure | grep -B3 -A3 something
The pipe character is defined as an alias for pipe command, so that
the above can be typed as:
(gdb) | print some_data_structure | grep -B3 -A3 something
If no GDB COMMAND is given, then the previous command is relaunched,
and its output is sent to the given SHELL_COMMAND.
This also defines convenience vars $_shell_exitcode and $_shell_exitsignal
to record the exit code and exit signal of the last shell command
launched by GDB e.g. by "shell", "pipe", ...
gdb/ChangeLog
2019-05-31 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* cli/cli-cmds.c (pipe_command): New function.
(_initialize_cli_cmds): Call add_com for pipe_command.
Define | as an alias for pipe.
(exit_status_set_internal_vars): New function.
(shell_escape): Call exit_status_set_internal_vars.
cli/cli-decode.c (find_command_name_length): Recognize | as
a single character command.
2019-05-31 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdbcmd.h (execute_command_to_ui_file): New declaration.
top.c (execute_command_to_ui_file): New function, mostly a copy
of execute_command_to_string.
(execute_command_to_string): Implement by calling
execute_command_to_ui_file.
Currently, a previous command can be repeated when the user types an
empty line. This is implemented in handle_line_of_input by
returning saved_command_line in case an empty line has been input.
If we want a command to repeat the previous command, we need to save
the previous saved_command_line, as when a command runs, the saved_command_line
already contains the current command line of the command being executed.
As suggested by Tom, the previous_saved_command_line is made static.
At the same time, saved_command_line is also made static.
The support functions/variables for the repeat command logic are now all
located inside top.c.
gdb/ChangeLog
2019-05-31 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* top.h (saved_command_line): Remove declaration.
* top.c (previous_saved_command_line, previous_repeat_arguments):
New variables.
(saved_command_line): Make static, define together with other
'repeat variables'.
(dont_repeat): Clear repeat_arguments.
(repeat_previous, get_saved_command_line, save_command_line):
New functions.
(gdb_init): Initialize saved_command_line
and previous_saved_command_line.
* main.c (captured_main_1): Remove saved_command_line initialization.
* event-top.c (handle_line_of_input): Update to use
the new 'repeat' related functions instead of direct access to
saved_command_line.
* command.h (repeat_previous, get_saved_command_line,
save_command_line): New declarations.
(dont_repeat): Add comment.
This fixes a couple of comments in gdbtypes.h. One comment had a
typo; and another comment referred to "Moto", which is presumably some
long-gone Motorola-related project.
Tested by rebuilding.
gdb/ChangeLog
2019-05-30 Tom Tromey <tromey@adacore.com>
* gdbtypes.h (struct range_bounds) <flag_upper_bound_is_count>:
Fix comment.
(TYPE_ARRAY_UPPER_BOUND_IS_UNDEFINED): Rewrite comment.
The complete function should set parameter word to the end of the
word to complete. However, completion_find_completion_word may fail,
leaving word uninitialized.
To make sure word is always set, initialize it to the completion point
which is the end of the line parameter.
gdb/Changelog
PR cli/24587
* completer.c (complete): Initialize variable word.
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 a failure in gdb.ada/complete.exp when testing locally:
FAIL: gdb.ada/complete.exp: complete break ada
This failed due to this output:
[...]
break ada/generated/gnatvsn.ads
break ada/libgnat/s-excmac.ads
break ada/sdefault.adb
break ada/snames.adb
break ada/snames.ads
This patch updates the regexp to allow "/" and "-" to appear.
gdb/testsuite/ChangeLog
2019-05-29 Tom Tromey <tromey@adacore.com>
* gdb.ada/complete.exp (test_gdb_no_completion): Add "/" and "-"
to "break complete ada" test case's regexp.
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.
PR c++/20020 concerns a crash in cp_print_value_fields. The immediate
cause is that cp_print_value_fields does not handle the case where
value_static_field fails. This is fixed in this patch by calling
cp_print_static_field from the "try" block.
Digging a bit deeper, the error occurs because GCC does not emit a
DW_AT_const_value for a static constexpr member appearing in a
template class. I've filed a GCC bug for this.
Tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-05-29 Tom Tromey <tromey@adacore.com>
PR c++/20020:
* cp-valprint.c (cp_print_value_fields): Call
cp_print_static_field inside "try".
gdb/testsuite/ChangeLog
2019-05-29 Tom Tromey <tromey@adacore.com>
PR c++/20020:
* gdb.cp/constexpr-field.exp: New file.
* gdb.cp/constexpr-field.cc: New file.
GCC 9 has a few new warnings that aren't enabled in the gdb build by
default: -Wdeprecated-copy, -Wdeprecated-copy-dtor, and
-Wredundant-move. This patch enables them all.
Tested by rebuilding with a new GCC (git master) on x86-64 Fedora 29.
gdb/ChangeLog
2019-05-29 Tom Tromey <tromey@adacore.com>
* inflow.c (struct terminal_info): Add default operator=.
* configure: Rebuild.
* warning.m4 (AM_GDB_WARNINGS): Add -Wdeprecated-copy,
-Wdeprecated-copy-dtor, -Wredundant-move.
gdb/gdbserver/ChangeLog
2019-05-29 Tom Tromey <tromey@adacore.com>
* configure: Rebuild.
A user wanted to be able to disable the display of the value when
using "finish" -- but still have the value entered into the value
history in case it was useful later on. Part of the rationale here is
that sometimes the value might be quite large, or expensive to display
(in their case this was compounded by a rogue pretty-printer).
This patch implements this idea.
gdb/ChangeLog
2019-05-29 Tom Tromey <tromey@adacore.com>
* NEWS: Add entry.
* infcmd.c (print_return_value_1): Handle finish_print
option.
(show_print_finish): New function.
(_initialize_infcmd): Add "set/show print finish" commands.
* valprint.c (user_print_options): Initialize new member.
* valprint.h (struct value_print_options) <finish_print>: New
member.
gdb/doc/ChangeLog
2019-05-29 Tom Tromey <tromey@adacore.com>
* gdb.texinfo (Continuing and Stepping): Document new
commands.
gdb/testsuite/ChangeLog
2019-05-29 Tom Tromey <tromey@adacore.com>
* gdb.base/finish.exp (finish_no_print): New proc.
(finish_tests): Call it.
We found a case where a "bt" was very slow with Ada code. Profiling
with callgrind showed this to be primarily due to calls to
find_old_style_renaming_symbol. Because new-style renaming symbols
were implemented in 2007, it seems safe enough to remove this old
code.
A "-batch -ex bt" test on a large Ada program improves from:
13.23user 0.57system 0:13.82elapsed 99%CPU (0avgtext+0avgdata 571408maxresident)k
to
4.25user 0.48system 0:04.74elapsed 99%CPU (0avgtext+0avgdata 559844maxresident)k
with this patch.
Tested on x86-64 Fedora 29. Joel reviewed this internally; and as it
is Ada-specific, I am checking it in.
gdb/ChangeLog
2019-05-28 Tom Tromey <tromey@adacore.com>
* ada-lang.c (ada_remove_Xbn_suffix)
(find_old_style_renaming_symbol)
(parse_old_style_renaming): Remove.
(ada_find_renaming_symbol): Don't call
find_old_style_renaming_symbol.
(ada_is_renaming_symbol): Rename from
ada_find_renaming_symbol. Remove "block" parameter. Return
bool. Now static.
(ada_read_var_value): Update and simplify.
* ada-exp.y (write_var_or_type): Remove old code.
Calls to error () can cause SIGTTOU to send gdb to the background.
For example, on an Arm build:
(gdb) b main
Breakpoint 1 at 0x10774: file /build/gdb/testsuite/../../../src/binutils-gdb/gdb/testsuite/gdb.base/watchpoint.c, line 174.
(gdb) r
Starting program: /build/gdb/testsuite/outputs/gdb.base/watchpoint/watchpoint
[1]+ Stopped ../gdb ./outputs/gdb.base/watchpoint/watchpoint
localhost$ fg
../gdb ./outputs/gdb.base/watchpoint/watchpoint
Cannot parse expression `.L1199 4@r4'.
warning: Probes-based dynamic linker interface failed.
Reverting to original interface.
The SIGTTOU is raised whilst inside a syscall during the call to tcdrain.
Fix is to use scoped_ignore_sigttou to ensure SIGTTOU is blocked.
In addition fix include comments - job_control is not included via terminal.h
gdb/ChangeLog:
* event-top.c: Remove include comment.
* inflow.c (class scoped_ignore_sigttou): Move from here...
* inflow.h (class scoped_ignore_sigttou): ...to here.
* ser-unix.c (hardwire_drain_output): Block SIGTTOU during drain.
* top.c: Remove include comment.
Add a test-case gdb.dwarf2/gdb-add-index.exp to test
gdb/contrib/gdb-add-index.sh.
Tested with x86_64-linux.
gdb/testsuite/ChangeLog:
2019-05-24 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/gdb-add-index.exp: New file.
I noticed that target_ops::follow_exec took a "char *" parameter,
where "const char *" would be more correct. This patch changes this
(and related functions) to be constified.
Tested by rebuilding.
gdb/ChangeLog
2019-05-22 Tom Tromey <tromey@adacore.com>
* target.c (target_follow_exec): Constify parameter.
* target-delegates.c: Rebuild.
* remote.c (remote_target::follow_exec): Constify parameter.
* infrun.c (follow_exec): Constify parameter.
* target.h (struct target_ops) <follow_exec>: Constify parameter.
(target_follow_exec): Likewise.
This adds a "style" helper proc to the test suite, and updates
existing style tests to use it. Thanks to Sergio for the idea.
Tested on x86-64 Fedora 29.
gdb/testsuite/ChangeLog
2019-05-22 Tom Tromey <tromey@adacore.com>
* gdb.base/info-shared.exp (check_info_shared): Use "style".
* gdb.base/style.exp: Use "style".
* lib/gdb-utils.exp (style): New proc.
When building gdb on ubuntu 16.04 with gcc 5.4.0, and running the gdb
testsuite we run into a failure due align.exp requiring at least c++11.
Fix this by adding -std=c++11.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-05-22 Tom de Vries <tdevries@suse.de>
* gdb.base/align.exp: Require c++11.
Fix gdb.python/py-mi-var-info-path-expression.exp for a gdb build without
python support.
gdb/testsuite/ChangeLog:
2019-05-22 Tom de Vries <tdevries@suse.de>
PR testsuite/24586
* gdb.python/py-mi-var-info-path-expression.exp: Call
mi_skip_python_tests to check if python is supported.
Running an address signed binary through GDB on a non pauth system
gives the following error:
Call Frame Instruction op 45 in vendor extension space is not handled on this architecture.
Instead GDB should ignore the op, treating it as a nop.
Add test case for pauth binaries, regardless of whether the target
supports it.
gdb/ChangeLog:
* aarch64-tdep.c (aarch64_execute_dwarf_cfa_vendor_op): Treat
DW_CFA_AARCH64_negate_ra_state as nop on non pauth targets.
gdb/testsuite/ChangeLog:
* gdb.arch/aarch64-pauth.c: New test.
* gdb.arch/aarch64-pauth.exp: New file.
Add missing documentation for the debugredirect setting.
Add description and uses of gdb.in/gdb.cmd to the testsuite README.
Mention this in the NEWS file.
gdb/ChangeLog:
* NEWS: Add debugredirect and testsuite sections.
gdb/doc/ChangeLog:
* gdb.texinfo (Shell Commands): Add debugredirect.
gdb/testsuite/ChangeLog:
* README (Re-running Tests Outside The Testsuite): New section.
This solves an assertion failure when a remote provides a target
description which only refers to floating point registers by their
hardware name (e.g. f0), rather than their ABI name (e.g. ft0). GDB
assumed that should the floating point register feature be presented,
it would contain a register called ft0.
The floating point length is now instead determined by searching for
the same register, but looking for any of its aliases.
gdb/ChangeLog:
* riscv-tdep.c (riscv_gdbarch_init): Support determining flen from
target descriptions using exclusively floating point register name
aliases.
In this commit:
commit 34d11c682f
Date: Fri May 3 15:23:55 2019 +0100
gdb/fortran: Use floatformats_ia64_quad for fortran 16-byte floats
GDB was changed such that the Fortran's 16-byte float format was
obtained by calling gdbarch_floatformat_for_type instead of just using
gdbarch_long_double_format as it was before.
The problem with this default_floatformat_for_type can return NULL in
some cases, and the code introduced in 34d11c682f didn't consider
this.
This commit introduces several alternative strategies for finding a
suitable 16-byte floating point type. First GDB calls
gdbarch_floatformat_for_type (this was what 34d11c682f added), if this
returns null GDB will use gdbarch_long_double_format if it is the
correct size (this was the format used before 34d11c682f). Finally,
if neither of the above provides a suitable type then GDB will create
a new dummy type.
This final dummy type is unlikely to provide an correct debug
experience as far as examining the 16-byte floats, but it should
prevent GDB crashing.
gdb/ChangeLog:
PR gdb/18644:
* f-lang.c (build_fortran_types): Handle the case where
gdbarch_floatformat_for_type returns a nullptr.
When building gdb on ubuntu 16.04 with gcc 5.4.0, and running the gdb
testsuite we run into:
...
FAIL: gdb.linespec/explicit.exp: complete after -line: \
cmd complete "b -line argument " (timeout)
...
The failure is reproducible outside the testsuite like this:
...
$ gdb -q build/gdb/testsuite/outputs/gdb.linespec/explicit/explicit \
-ex "complete b -line argument"
Reading symbols from \
build/gdb/testsuite/outputs/gdb.linespec/explicit/explicit...
terminate called after throwing an instance of 'std::length_error'
what(): basic_string::_M_create
Aborted (core dumped)
...
The problem is here in complete_command:
...
completion_result result = complete (arg, &word, "e_char);
std::string arg_prefix (arg, word - arg);
if (result.number_matches != 0)
...
The problem is that the word variable is not initialized when
result.number_matches == 0, but the variable is still used in the arg_prefix
initialization.
Fix this by guarding the arg_prefix initialization with the
'result.number_matches != 0' test.
Build and tested on x86_64-linux.
gdb/ChangeLog:
2019-05-21 Tom de Vries <tdevries@suse.de>
PR cli/24587
* cli/cli-cmds.c (complete_command): Fix use of unitialized variable.
When building gdb on ubuntu 16.04 with gcc 5.4.0, and running the gdb
testsuite we run into failures due test-cases requiring at least c++1.
Fix this by adding -std=c++11 to those test-cases.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-05-21 Tom de Vries <tdevries@suse.de>
* gdb.arch/amd64-eval.exp: Require c++11.
* gdb.base/max-depth.exp: Same.
* gdb.compile/compile-cplus-array-decay.exp: Same.
* gdb.cp/meth-typedefs.exp: Same.
* gdb.cp/subtypes.exp: Same.
* gdb.cp/temargs.exp: Same.
This matches the kill in gdb_file_cmd, and ensures that the command is not
sent to the gdb.in file.
When gdb.in is used as a batch file, any kill commands run before the target
is started will cause gdb to stop processing commands.
gdb/testsuite/ChangeLog:
* lib/gdbserver-support.exp (gdbserver_run): Mark kill as optional.
PR gdb/18644 is caused by GDB using the wrong floating point format
for gfortran's 16-byte floating point type, including when the 16-byte
float is used as the component of a 32-byte complex type.
This commit addresses the issue in two places, first in i386-tdep.c,
there is already some code to force the use of floatformats_ia64_quad
for specific named types, this is extended to include the type names
that gfortran uses for its 16-byte floats.
Second, the builtin 16-byte float type (in f-lang.c) is changed so it
no longer uses gdbarch_long_double_format. On i386 this type is not
16-bytes, but is smaller, this is not what gfortran is expecting.
Instead we now use gdbarch_floatformat_for_type and ask for a
16-byte (128 bit) type using the common gfortran type name. This is
then spotted in i386-tdep.c (thanks to the first change above) and we
again get floatformats_ia64_quad returned.
This patch was tested on X86-64/GNU-Linux using '--target_board=unix'
and '--target_board=unix/-m32', and resolves all of the known failures
associated with PR gdb/18644. I've also added the test case from the
original bug report.
gdb/ChangeLog:
PR gdb/18644:
* f-lang.c (build_fortran_types): Use floatformats_ia64_quad for
16-byte floats.
* i386-tdep.c (i386_floatformat_for_type): Use
floatformats_ia64_quad for the 16-byte floating point component
within a fortran 32-byte complex number.
gdb/testsuite/ChangeLog:
PR gdb/18644
* gdb.fortran/complex.exp: Remove setup_kfail calls.
* gdb.fortran/printing-types.exp: Add new test.
* gdb.fortran/printing-types.f90: Add 16-byte real variable for
testing.
* gdb.fortran/type-kinds.exp (test_cast_1_to_type_kind): Remove
setup_kfail call.
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.
find_and_open_source casts away const, but hasn't needed to in a
while. This removes the cast and a strangely hostile comment.
gdb/ChangeLog
2019-05-17 Tom Tromey <tromey@adacore.com>
* source.c (find_and_open_source): Remove cast.
I noticed that annotate_source takes a "char *", but really should
take a "const char *". This patch fixes this.
gdb/ChangeLog
2019-05-17 Tom Tromey <tromey@adacore.com>
* annotate.c (annotate_source): Make "filename" const.
* annotate.h (annotate_source): Use const.
TRANSCRIPT is superseeded by the .in, .cmd and .debug files, and
can be removed.
gdb/testsuite/ChangeLog
* README (Running the Testsuite): Change example.
(Testsuite Parameters): Remove TRANSCRIPT.
* lib/gdb.exp: Remove TRANSCRIPT check.
Add "replay" to the list of GDBSERVER_DEBUG options. This will
cause a gdbserver.replay file to be written to the test output
directory.
At the same time switch this to a comma separated list in order
to easily handle all possible options.
The replay log is created by GDB, but has been added to
GDBSERVER_DEBUG as it is only required for gdbserver tests. To
enable it, the gdb_debug_init is overridden to allow the additional
checking, before calling the original function.
gdb/testsuite/ChangeLog:
* README (Testsuite Parameters): Add replay logging to
GDBSERVER_DEBUG.
(gdbserver,debug): Refer to GDBSERVER_DEBUG.
* lib/gdbserver-support.exp (gdbserver_start): Treat gdbserverdebug
as a comma separated list.
(gdb_debug_init): Override procedure.
When spawning gdb or gdbserver create a .cmd file in the test output
directory containing the full command line, ensuring the current gdb
instance is appended to the files so that they can be quickly matched
to the corresponding gdb.in file.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (default_gdb_spawn): Call gdb_write_cmd_file.
(gdb_write_cmd_file): New procedure.
* lib/gdbserver-support.exp (gdbserver_start): Call
gdbserver_write_cmd_file.
(gdbserver_write_cmd_file): New proedure.
When debugging testsuite failures, it can be awkward parsing gdb.log to
obtain all the commands run in order to manually re-run the test.
This patch adds the functionality to save all gdb commands to the file gdb.in
when the testsuite is run. The file is saved in the directory for the test and
if gdb is restarted then .1, .2, .3 etc is added to the filename.
Once a test has been run, the .in file can be used to re-run the test in the
following way:
gdb -x outputs/gdb.store/gdb.in outputs/gdb.store/store
The code works by intercepting send_gdb. I've added a TYPE to ensure that any
commands that would destroy the playback are kept from the log (for example the
Y from an answer to a y/n question).
Adds library function standard_output_file_with_gdb_instance to open a file
postfixed with count of the gdb instance. Ensure this count is reset when a new
.exp script is run.
I've re-run a random selection of .in files to check they do not error. Logs with
commands such as "attach <pid>" will not directly work when re-run.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (gdb_unload): Mark Y as an answer.
(delete_breakpoints): Likewise.
(gdb_run_cmd): Likewise.
(gdb_start_cmd): Likewise.
(gdb_starti_cmd): Likewise.
(gdb_internal_error_resync): Likewise.
(gdb_test_multiple): Likewise.
(gdb_reinitialize_dir): Likewise.
(default_gdb_exit): Likewise.
(gdb_file_cmd): Mark kill as optional.
(default_gdb_start): Call gdb_stdin_log_init.
(send_gdb): Call gdb_stdin_log_write.
(rerun_to_main): Mark Y as an answer.
(gdb_stdin_log_init): New function.
(gdb_stdin_log_write): Likewise.
Fix up all failures encountered when running the testsuite with
GDB_DEBUG="infrun".
Some tests rely on enabling debugging for various components. With
debugging on, this will be lost to the debug file.
Disable separate tty for mi tests when debugging. This currently
does not work.
disasm.c should send errors to the stderr instead of the logfile.
Note that enabling debug for other components might still cause
additional errors above what has been fixed here.
gdb/ChangeLog:
* disasm.c (set_disassembler_options): Send errors to stderr.
gdb/testsuite/ChangeLog:
* gdb.base/breakpoint-in-ro-region.exp: Disable when debugging.
* gdb.base/debug-expr.exp: Likewise.
* gdb.base/foll-fork.exp: Likewise.
* gdb.base/foll-vfork.exp: Likewise.
* gdb.base/fork-print-inferior-events.exp: Likewise.
* gdb.base/gdb-sigterm.exp: Likewise.
* gdb.base/gdbinit-history.exp: Likewise.
* gdb.base/osabi.exp: Likewise.
* gdb.base/sss-bp-on-user-bp-2.exp: Likewise.
* gdb.base/ui-redirect.exp: Likewise.
* gdb.gdb/unittest.exp: Likewise.
* gdb.mi/mi-break.exp: Disable separate-mi-tty when debugging.
* gdb.mi/mi-watch.exp: Likewise.
* gdb.mi/new-ui-mi-sync.exp: Likewise.
* gdb.mi/user-selected-context-sync.exp: Likewise.
* gdb.python/python.exp: Disable debug test when debugging.
* gdb.threads/check-libthread-db.exp: Disable when debugging.
* gdb.threads/signal-while-stepping-over-bp-other-thread.exp:
Likewise.
* gdb.threads/stepi-random-signal.exp: Likewise.
Add both board option and environment variable which enables gdb
debug via a comma separated list and sends it to the file gdb.debug,
located in the output directory for the current test. Document this.
Add support for the environment variable in the Makefile.
The testsuite can be run with gdb debug enabled in the following way:
make check GDB_DEBUG="infrun,target,remote"
A Test with multiple invocations of GDB will all append debug to the
same log file.
gdb/testsuite/ChangeLog:
* Makefile.in: Pass through GDB_DEBUG.
* README (Testsuite Parameters): Add GDB_DEBUG.
(gdb,debug): Add board setting.
* lib/gdb.exp (default_gdb_start): Start debugging.
(gdb_debug_enabled): New procedure.
(gdb_debug_init): Likewise.
Currently, when logging is enabled, output will be sent to both a
logfile and standard terminal output. The redirect option sends output
only to the logfile. This includes all debug output.
Add the option to redirect debug output seperately to normal
output, using the cli command:
set logging debugredirect on
By setting this and enabling logging, all output and debug will
be sent to the logfile. The user will still see all output but
no debug output.
This causes a change in behaviour for anyone currently using
logging redirect, as now only output will be redirected. Users
will have to issue the additional command above to also redirect
debug.
Expand ui-redirect.exp cover the changes.
gdb/ChangeLog:
* cli/cli-interp.c (struct saved_output_files): Add saved entry.
(cli_interp_base::set_logging): Check debug_redirect.
* cli/cli-interp.h (set_logging): Add debug_redirect parameter.
* cli/cli-logging.c (debug_redirect): Add static variable.
(pop_output_files): Add default param.
(handle_redirections): Print debug setting.
(show_logging_command): Likewise.
(_initialize_cli_logging): Add debugredirect command.
* interps.c (current_interp_set_logging): Add debug_redirect
parameter.
* interps.h (set_logging): Add debug_redirect parameter.
(current_interp_set_logging): Likewise.
* mi/mi-common.h: Likewise.
* mi/mi-interp.c (mi_interp::set_logging): Likewise.
gdb/testsuite/ChangeLog:
* gdb.base/ui-redirect.exp: Add debug redirect tests.
Instead of using two bools to decide if the files should close when tee_file
is closed, make file one stay open and file two close. This simplifies the
use cases for it.
Inline the make_logging_output into the calling functions (the logic here
looks ugly in order to simplify a later change).
Expand ui-redirect.exp to cover the changes, similar to mi-logging.exp.
gdb/ChangeLog:
* cli/cli-interp.c (cli_interp_base::set_logging): Create tee_file
directly.
* cli/cli-interp.h (make_logging_output): Remove declaration.
* cli/cli-logging.c (make_logging_output): Remove function.
* mi/mi-interp.c (mi_interp::set_logging): Create tee_file
directly.
* ui-file.c (tee_file::tee_file): Remove bools.
(tee_file::~tee_file): Remove deletes.
* ui-file.h (tee_file): Remove bools.
gdb/testsuite/ChangeLog:
* gdb.base/ui-redirect.exp: Test redirection.
There is a CLI command 'complete' intended to use with emacs. Such a command
would also be useful for MI frontends, when separate CLI and MI channels cannot
be used. For example, on Windows (because of lack of PTYs) or when GDB is used
through SSH session.
This commit adds a new '-complete' MI command.
gdb/Changelog:
2019-01-28 Jan Vrany <jan.vrany@fit.cvut.cz>
* mi/mi-cmds.h (mi_cmd_complete): New function.
* mi/mi-main.c (mi_cmd_complete): Likewise.
* mi/mi-cmds.c: Define new MI command -complete.
* NEWS: Mention new -complete command.
gdb/doc/ChangeLog:
2019-01-28 Jan Vrany <jan.vrany@fit.cvut.cz>
* gdb.texinfo (Miscellaneous GDB/MI Commands): Document new
MI command -complete.
gdb/testsuite/ChangeLog:
2019-01-28 Jan Vrany <jan.vrany@fit.cvut.cz>
* gdb.mi/mi-complete.exp: New file.
* gdb.mi/mi-complete.cc: Likewise.
Extract completion logic from CLI complete_command() into a new
helper function complete().
gdb/Changelog:
* completer.h (complete): New function.
* completer.c (complete): Likewise.
* cli/cli-cmds.c: (complete_command): Update to use new complete()
function defined in completer.h.
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.
This patch simplifies the code of
stap-probe.c:stap_parse_register_operand by making "regname" an
std::string. No functionality change.
I'm this code's maintainer, so I'm pushing this as it's a fairly
trivial patch.
gdb/ChangeLog:
2019-05-16 Sergio Durigan Junior <sergiodj@redhat.com>
* stap-probe.c (stap_parse_register_operand): Make "regname" an
"std::string", simplifying the algorithm.
I think the string formatting for complaints was messed up by Tom's
patch to simplify the complaint mechanism. This small and trivial
patch fixes them.
Pushed as obvious.
gdb/ChangeLog:
2019-05-16 Sergio Durigan Junior <sergiodj@redhat.com>
* stap-probe.c (handle_stap_probe): Fix complaint formatting.
(stap_static_probe_ops::get_probes): Likewise.
This patch contains three very small improvement on the logic of some
operations we do on stap-probe.c. They don't change what the code
does.
Pushed as obvious.
gdb/ChangeLog:
2019-05-16 Sergio Durigan Junior <sergiodj@redhat.com>
* stap-probe.c (stap_parse_register_operand): Make "if (*p->arg ==
'-')" and "else if".
(stap_parse_single_operand): Join checks for
"gdbarch_stap_parse_special_token_p" and
"gdbarch_stap_parse_special_token" in the same "if" statement.
Invert check when verifying for operation on register
displacement.
Some functions's comments were not entirely correct on stap-probe.c,
so this patch updates them.
Pushed as obvious.
gdb/ChangeLog:
2019-05-16 Sergio Durigan Junior <sergiodj@redhat.com>
* stap-probe.c (stap_get_opcode): Update comment.
(stap_get_expected_argument_type): Likewise.
(handle_stap_probe): Likewise.
This simple patch converts a bunch of "int"s to "bool" on stap-probe.c
and on the stap-related code present on i386-tdep.c.
Pushed as obvious (+ I'm the maintainer of this code).
gdb/ChangeLog:
2019-05-16 Sergio Durigan Junior <sergiodj@redhat.com>
* i386-tdep.c (i386_stap_parse_special_token_triplet): Change
return type to 'bool'. Adjust comment. Use 'bool' when
appropriate.
(i386_stap_parse_special_token_three_arg_disp): Likewise.
* stap-probe.c (stap_parse_argument_1): Likewise.
(stap_is_operator): Likewise.
(stap_is_generic_prefix): Likewise.
(stap_is_register_prefix): Likewise.
(stap_is_register_indirection_prefix): Likewise.
(stap_is_integer_prefix): Likewise.
(stap_generic_check_suffix): Likewise.
(stap_check_integer_suffix): Likewise.
(stap_check_register_suffix): Likewise.
(stap_check_register_indirection_suffix): Likewise.
(stap_parse_register_operand): Likewise.
(stap_parse_single_operand): Likewise.
(stap_parse_argument_1): Likewise.
(stap_probe::get_argument_count): Likewise.
(stap_is_operator): Likewise.
John Marshall pointed out that darwin-nat.c fails to build:
CXX darwin-nat.o
../../../binutils-gdb/gdb/darwin-nat.c:1709:8: error: must use 'class' tag to refer to type 'thread_info' in this scope
for (thread_info *it : all_threads ())
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/mach/thread_act.h:240:15: note:
class 'thread_info' is hidden by a non-type declaration of 'thread_info' here
kern_return_t thread_info
Mach has a thread_info() function declared in that header, which darwin-nat.c #includes.
This patch fixes the problem by reintroducing the struct keyword.
gdb/ChangeLog
2019-05-16 Tom Tromey <tromey@adacore.com>
* darwin-nat.c (thread_info_from_private_thread_info): Add struct
keyword to foreach.
Add tests for calling sizeof on indexed and sliced arrays, and on
pointers to arrays. These are all things that currently work, but
were previously untested.
gdb/testsuite/ChangeLog:
* gdb.fortran/vla-sizeof.exp: Add tests of sizeof applied to
indexed and sliced arrays, and pointers to arrays.
I happened to be looking at this code and noticed we could replace ints
by bools at a few places.
gdb/ChangeLog:
* linux-thread-db.c (try_thread_db_load_1): Change return type
to bool.
(try_thread_db_load): Likewise.
(try_thread_db_load_from_pdir_1): Likewise.
(try_thread_db_load_from_pdir): Likewise.
(try_thread_db_load_from_sdir): Likewise.
(try_thread_db_load_from_dir): Likewise.
(thread_db_load_search): Likewise.
(has_libpthread): Likewise.
(thread_db_load): Likewise.
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.
Previously, the stack unwinder searched through consecutive bytes for values
which it thought might be the start of a stack mutating operation.
This was error prone, because such bytes could also be the operands of other
instructions. This change uses the opcodes api to interpret the code in each
frame.
gdb/ChangeLog:
* s12z-tdep.c (push_pull_get_stack_adjustment): New function.
(advance, posn, abstract_read_memory): New functions.
[struct mem_read_abstraction]: New struct.
(s12z_frame_cache): Use opcodes API to interpret stack frame code.
coerce_unspec_val_to_type does:
set_value_address (result, value_address (val));
However, this is only valid for lval_memory. This patch changes this
code to only set the address for lval_memory values.
This seems like an ordinary oversight in coerce_unspec_val_to_type,
and a test case would be difficult to write, so I'm submitting it
without a test case.
Tested on x86-64 Fedora 29; plus using an Ada program that exhibits
the bug (but which cannot be shared).
gdb/ChangeLog
2019-05-14 Tom Tromey <tromey@adacore.com>
* ada-lang.c (coerce_unspec_val_to_type): Only set address when
value is not lval_memory.
The "automatic symbol index cache" entry in the docs is missing entries in the
concept and command indices. Add them.
gdb/doc/ChangeLog:
2019-05-14 Tom de Vries <tdevries@suse.de>
* gdb.texinfo (Automatic symbol index cache): Add concept and command
index entries.
A base address selection entry in a location list consist of two (constant or
relocated) address offsets. The two offsets are the same size as an address
on the target machine.
The test-case gdb.dwarf2/dw2-skip-prologue.S encodes a base address selection
entry using .4byte, which is incorrect for 8-byte pointer size. [ Which
triggers an assert in dwz, see PR dwz/24172. ]
Fix this by using PTRBYTE instead.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-05-14 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/dw2-skip-prologue.S (.debug_loc): Fix base address
selection entry encoding.
Currently, the entry for the command "maint info selftests" in the Command,
Variable, and Function Index is listed at '"', rather than next to the other
"maint info" commands.
Fix this by removing the superfluous quoting in the @kindex entry.
gdb/doc/ChangeLog:
2019-05-14 Tom de Vries <tdevries@suse.de>
* gdb.texinfo (Maintenance Commands): Remove superfluous
quoting on command index entry for "maint info selftests".
Since commit
b4be1b0648 ("Fix MI output for multi-location breakpoints")
we get this error when building with --disable-gdbmi:
CXXLD gdb
/home/smarchi/src/binutils-gdb/gdb/breakpoint.c:6358: error: undefined reference to 'mi_multi_location_breakpoint_output_fixed(ui_out*)'
This is due to breakpoint.c using a function defined in mi/mi-main.c, even
though mi/mi-main.c isn't included in the build.
To fix it, use the flags feature of ui_out. mi_ui_out has the new
fix_multi_location_breakpoint_output flag set for versions >= 3. Also,
move the global variable fix_multi_location_breakpoint_output to
breakpoint.c, so it can be read there even when we build without MI. I
renamed it to fix_multi_location_breakpoint_output_globally so it
doesn't clash with the new enumerator.
gdb/ChangeLog:
* breakpoint.h (fix_multi_location_breakpoint_output_globally):
New variable declaration.
* breakpoint.c (fix_multi_location_breakpoint_output_globally):
New variable.
(print_one_breakpoint): Use ui_out::test_flags and new global
variable to compute use_fixed_output.
* mi/mi-main.h (mi_multi_location_breakpoint_output_fixed):
Remove.
* mi/mi-main.c (fix_multi_location_breakpoint_output): Remove.
(mi_multi_location_breakpoint_output_fixed): Remove.
(mi_cmd_fix_multi_location_breakpoint_output): Adjust to set the
new variable.
* mi/mi-out.c (mi_ui_out::mi_ui_out): Set
fix_multi_location_breakpoint_output flag if version >= 3.
* ui-out.h (enum ui_out_flag)
<fix_multi_location_breakpoint_output>: New enumerator.
When running the gdb.base/index-cache.exp test case with the
cc-with-dwz-m board, I noticed that the final executable didn't actually
contain a .gnu_debugaltlink section with the name of the external dwz
file:
$ readelf --debug-dump=links testsuite/outputs/gdb.base/index-cache/index-cache
* empty *
Running dwz by hand, I realized it's because dwz complains that the
output .debug_info section is empty and fails:
$ gcc ~/src/binutils-gdb/gdb/testsuite/gdb.base/index-cache.c -g3 -O0 -o a && cp a b
$ dwz -m foo a b
dwz: foo: .debug_info section not present
$ echo $?
1
This is because index-cache.c is trivial (just an empty main) and dwz
doesn't find anything to factor out to the dwz file. [1]
I think that cc-with-tweaks should fail in this scenario: if the user
asks for an external dwz file to be generated (the -m flag), then it
should be an error if cc-with-tweaks doesn't manage to produce an
executable with the proper link to this external dwz file. Otherwise,
the test runs with a regular non-dwzified executable, which gives a
false sense of security about whether the feature under test works with
dwzified executables.
So this patch adds checks for that after invoking dwz. It also removes
the 2>&1 to allow the error message to be printed like so:
Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/index-cache.exp ...
gdb compile failed, dwz: /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/index-cache/index-cache.dwz: .debug_info section not present
- In the -m case (multi-file compression), we check if the expected output file
exists.
- In the -z case (single-file compression), we check if the file
contents has changed. This should catch cases where dwz doesn't modify the
file because it's not worth it.
It was chosen not to check for dwz's exit code, as it is not very
reliable up to dwz 0.12.
With this patch, fewer tests will pass than before with the
cc-with-dwz and cc-with-dwz-m boards, but those were false positives
anyway, as the test ran with regular executables.
[1] Note that dwz has been patched by Tom de Vries to work correctly in
this case, so we can use dwz master to run the test:
https://sourceware.org/git/?p=dwz.git;a=commit;h=08becc8b33453b6d013a65e7eeae57fc1881e801
gdb/ChangeLog:
* contrib/cc-with-tweaks.sh: Validate dwz's work.
I found out recently that some users didn't know that the Python
pretty-printers "children" method should compute its result lazily.
This has been a good idea since the earliest days, but wasn't
mentioned in the docs. This patch adds some text to this effect.
gdb/doc/ChangeLog
2019-05-10 Tom Tromey <tromey@adacore.com>
* python.texi (Pretty Printing API): Mention lazy computation for
"children".
This patch adds a completion function to the "catch exception"
and "catch handlers" commands.
Tested on x86-64 Fedora 29; reviewed off-list by Joel.
gdb/ChangeLog
2019-05-10 Tom Tromey <tromey@adacore.com>
* ada-lang.c (catch_ada_completer): New function.
(_initialize_ada_language): Use it.
gdb/testsuite/ChangeLog
2019-05-10 Tom Tromey <tromey@adacore.com>
* gdb.ada/info_exc.exp: Add "complete" test.
This patch makes a few minor improvements to the catchpoint
documentation:
* "catch exception" and "catch handlers" now mention the argument in
the @item.
* "catch exception unhandled" is moved to be closer to "catch
exception", rather than after "catch handlers".
* "catch load" and "catch unload" now wrap the argument in @var.
gdb/doc/ChangeLog
2019-05-10 Tom Tromey <tromey@adacore.com>
* gdb.texinfo (Set Catchpoints): Add text for parameter to "catch
exception" and "catch handlers". Move "catch exception unhandled"
text. Use @var for "catch load" and "catch unload"
I noticed a couple of spots where a "char *" was used where a
"const char *" made more sense. This patch fixes both of them.
Tested by rebuilding.
gdb/ChangeLog
2019-05-10 Tom Tromey <tromey@adacore.com>
* thread.c (print_thread_info): Make "requested_threads" const.
* gdbthread.h (print_thread_info): Make "requested_threads"
const.
* ada-tasks.c (print_ada_task_info): Make "taskno_str" const.
* ada-lang.h (print_ada_task_info): Make "taskno_str" const.
The test-case gdb.arch/amd64-tailcall-self.exp fails here:
...
if ![runto b] {
return -1
}
...
like:
...
(gdb) file build/gdb/testsuite/outputs/gdb.arch/amd64-tailcall-self/\
amd64-tailcall-self
Reading symbols from build/gdb/testsuite/outputs/gdb.arch/\
amd64-tailcall-self/amd64-tailcall-self...
Dwarf Error: Cannot find DIE at 0x1f5 referenced from DIE at 0x107 [in \
module build/gdb/testsuite/outputs/gdb.arch/amd64-tailcall-self/\
amd64-tailcall-self]
...
The problem is that in amd64-tailcall-self.S, CU-relative references are
assigned .debug_info section relative values. [ This is similar to the
problem fixed by "Fix gdb.arch/amd64-entry-value-paramref.S". ]
Fix this by assigning CU-relative references instead.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-05-09 Tom de Vries <tdevries@suse.de>
* gdb.arch/amd64-tailcall-self.S: Make DW_FORM_ref4 references
CU-relative.
The file gdb.arch/amd64-entry-value-paramref.S contains a DIE for function
bar:
...
DIE29: .uleb128 0x2 # (DIE (0x29) DW_TAG_subprogram)
.ascii "bar\0" # DW_AT_name
.byte 0x1 # DW_AT_decl_file (gdb.arch/amd64-entry-value-paramref.cc)
.byte 0x15 # DW_AT_decl_line
.long DIE45 # DW_AT_type
.byte 0x1 # DW_AT_inline
...
which refers to DIE45:
...
DIE45: .uleb128 0x4 # (DIE (0x45) DW_TAG_base_type)
.byte 0x4 # DW_AT_byte_size
.byte 0x5 # DW_AT_encoding
.ascii "int\0" # DW_AT_name
...
using a form DW_FORM_ref4:
...
.uleb128 0x2 # (abbrev code)
.uleb128 0x2e # (TAG: DW_TAG_subprogram)
.byte 0x1 # DW_children_yes
...
.uleb128 0x49 # (DW_AT_type)
.uleb128 0x13 # (DW_FORM_ref4)
...
However, the DW_FORM_ref4 is a CU-relative reference, while using a label for
the value will result in a section-relative value.
So, if linked in object files contain dwarf info and are placed in the
.debug_info section before the compilation units generated from
amd64-entry-value-paramref.S, then the referenced type is at 0x108:
...
<1><108>: Abbrev Number: 4 (DW_TAG_base_type)
<109> DW_AT_byte_size : 4
<10a> DW_AT_encoding : 5 (signed)
<10b> DW_AT_name : int
...
but the reference will point to a non-existing DIE at 0x1cf:
...
<1><f0>: Abbrev Number: 2 (DW_TAG_subprogram)
<f1> DW_AT_name : bar
<f5> DW_AT_decl_file : 1
<f6> DW_AT_decl_line : 21
<f7> DW_AT_type : <0x1cf>
<fb> DW_AT_inline : 1 (inlined)
...
which happens to cause a GDB internal error described in PR23270 - "GDB
internal error: dwarf2read.c:18656: internal-error: could not find partial
DIE 0x1b7 in cache".
Fix the invalid DWARF by making the reference value CU-relative:
...
- .long DIE45 # DW_AT_type
+ .long DIE45 - .Ldebug_info0 # DW_AT_type
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-05-09 Tom de Vries <tdevries@suse.de>
* gdb.arch/amd64-entry-value-paramref.S: Make DW_FORM_ref4 references
CU-relative.
This changes gdbtypes.c to use the type-safe registry API.
gdb/ChangeLog
2019-05-08 Tom Tromey <tom@tromey.com>
* gdbtypes.c (objfile_type_data): Change type.
(objfile_type, _initialize_gdbtypes): Update.
Tom Tromey
Tom Tromey
Tom de Vries
Tom Tromey
Andrew Burgess
Руслан Ижбулатов
Amos Bird
Pedro Alves
Christian Biesinger via gdb-patches
Philippe Waroquiers
Jan Vrany
Sergio Durigan Junior
Alan Hayward
Simon Cook
Simon Marchi
John Darrington
Simon Marchi
Joel Brobecker