| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
When building gdb with -O0 -fsanitize=address, and running test-case
gdb.ada/uninitialized_vars.exp, I run into:
...
(gdb) info locals
a = 0
z = (a => 1, b => false, c => 2.0)
=================================================================
==66372==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000097f58 at pc 0xffff52c0da1c bp 0xffffc90a1d40 sp 0xffffc90a1d80
READ of size 4 at 0x602000097f58 thread T0
#0 0xffff52c0da18 in memmove (/lib64/libasan.so.8+0x6da18)
#1 0xbcab24 in unsigned char* std::__copy_move_backward<false, true, std::random_access_iterator_tag>::__copy_move_b<unsigned char const, unsigned char>(unsigned char const*, unsigned char const*, unsigned char*) /usr/include/c++/13/bits/stl_algobase.h:748
#2 0xbc9bf4 in unsigned char* std::__copy_move_backward_a2<false, unsigned char const*, unsigned char*>(unsigned char const*, unsigned char const*, unsigned char*) /usr/include/c++/13/bits/stl_algobase.h:769
#3 0xbc898c in unsigned char* std::__copy_move_backward_a1<false, unsigned char const*, unsigned char*>(unsigned char const*, unsigned char const*, unsigned char*) /usr/include/c++/13/bits/stl_algobase.h:778
#4 0xbc715c in unsigned char* std::__copy_move_backward_a<false, unsigned char const*, unsigned char*>(unsigned char const*, unsigned char const*, unsigned char*) /usr/include/c++/13/bits/stl_algobase.h:807
#5 0xbc4e6c in unsigned char* std::copy_backward<unsigned char const*, unsigned char*>(unsigned char const*, unsigned char const*, unsigned char*) /usr/include/c++/13/bits/stl_algobase.h:867
#6 0xbc2934 in void gdb::copy<unsigned char const, unsigned char>(gdb::array_view<unsigned char const>, gdb::array_view<unsigned char>) gdb/../gdbsupport/array-view.h:223
#7 0x20e0100 in value::contents_copy_raw(value*, long, long, long) gdb/value.c:1239
#8 0x20e9830 in value::primitive_field(long, int, type*) gdb/value.c:3078
#9 0x20e98f8 in value_field(value*, int) gdb/value.c:3095
#10 0xcafd64 in print_field_values gdb/ada-valprint.c:658
#11 0xcb0fa0 in ada_val_print_struct_union gdb/ada-valprint.c:857
#12 0xcb1bb4 in ada_value_print_inner(value*, ui_file*, int, value_print_options const*) gdb/ada-valprint.c:1042
#13 0xc66e04 in ada_language::value_print_inner(value*, ui_file*, int, value_print_options const*) const (/home/vries/gdb/build/gdb/gdb+0xc66e04)
#14 0x20ca1e8 in common_val_print(value*, ui_file*, int, value_print_options const*, language_defn const*) gdb/valprint.c:1092
#15 0x20caabc in common_val_print_checked(value*, ui_file*, int, value_print_options const*, language_defn const*) gdb/valprint.c:1184
#16 0x196c524 in print_variable_and_value(char const*, symbol*, frame_info_ptr, ui_file*, int) gdb/printcmd.c:2355
#17 0x1d99ca0 in print_variable_and_value_data::operator()(char const*, symbol*) gdb/stack.c:2308
#18 0x1dabca0 in gdb::function_view<void (char const*, symbol*)>::bind<print_variable_and_value_data>(print_variable_and_value_data&)::{lambda(gdb::fv_detail::erased_callable, char const*, symbol*)#1}::operator()(gdb::fv_detail::erased_callable, char const*, symbol*) const gdb/../gdbsupport/function-view.h:305
#19 0x1dabd14 in gdb::function_view<void (char const*, symbol*)>::bind<print_variable_and_value_data>(print_variable_and_value_data&)::{lambda(gdb::fv_detail::erased_callable, char const*, symbol*)#1}::_FUN(gdb::fv_detail::erased_callable, char const*, symbol*) gdb/../gdbsupport/function-view.h:299
#20 0x1dab34c in gdb::function_view<void (char const*, symbol*)>::operator()(char const*, symbol*) const gdb/../gdbsupport/function-view.h:289
#21 0x1d9963c in iterate_over_block_locals gdb/stack.c:2240
#22 0x1d99790 in iterate_over_block_local_vars(block const*, gdb::function_view<void (char const*, symbol*)>) gdb/stack.c:2259
#23 0x1d9a598 in print_frame_local_vars gdb/stack.c:2380
#24 0x1d9afac in info_locals_command(char const*, int) gdb/stack.c:2458
#25 0xfd7b30 in do_simple_func gdb/cli/cli-decode.c:95
#26 0xfe5a2c in cmd_func(cmd_list_element*, char const*, int) gdb/cli/cli-decode.c:2735
#27 0x1f03790 in execute_command(char const*, int) gdb/top.c:575
#28 0x1384080 in command_handler(char const*) gdb/event-top.c:566
#29 0x1384e2c in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) gdb/event-top.c:802
#30 0x1f731e4 in tui_command_line_handler gdb/tui/tui-interp.c:104
#31 0x1382a58 in gdb_rl_callback_handler gdb/event-top.c:259
#32 0x21dbb80 in rl_callback_read_char readline/readline/callback.c:290
#33 0x1382510 in gdb_rl_callback_read_char_wrapper_noexcept gdb/event-top.c:195
#34 0x138277c in gdb_rl_callback_read_char_wrapper gdb/event-top.c:234
#35 0x1fe9b40 in stdin_event_handler gdb/ui.c:155
#36 0x35ff1bc in handle_file_event gdbsupport/event-loop.cc:573
#37 0x35ff9d8 in gdb_wait_for_event gdbsupport/event-loop.cc:694
#38 0x35fd284 in gdb_do_one_event(int) gdbsupport/event-loop.cc:264
#39 0x1768080 in start_event_loop gdb/main.c:408
#40 0x17684c4 in captured_command_loop gdb/main.c:472
#41 0x176cfc8 in captured_main gdb/main.c:1342
#42 0x176d088 in gdb_main(captured_main_args*) gdb/main.c:1361
#43 0xb73edc in main gdb/gdb.c:39
#44 0xffff519b09d8 in __libc_start_call_main (/lib64/libc.so.6+0x309d8)
#45 0xffff519b0aac in __libc_start_main@@GLIBC_2.34 (/lib64/libc.so.6+0x30aac)
#46 0xb73c2c in _start (/home/vries/gdb/build/gdb/gdb+0xb73c2c)
0x602000097f58 is located 0 bytes after 8-byte region [0x602000097f50,0x602000097f58)
allocated by thread T0 here:
#0 0xffff52c65218 in calloc (/lib64/libasan.so.8+0xc5218)
#1 0xcbc278 in xcalloc gdb/alloc.c:97
#2 0x35f21e8 in xzalloc(unsigned long) gdbsupport/common-utils.cc:29
#3 0x20de270 in value::allocate_contents(bool) gdb/value.c:937
#4 0x20edc08 in value::fetch_lazy() gdb/value.c:4033
#5 0x20dadc0 in value::entirely_covered_by_range_vector(std::vector<range, std::allocator<range> > const&) gdb/value.c:229
#6 0xcb2298 in value::entirely_optimized_out() gdb/value.h:560
#7 0x20ca6fc in value_check_printable gdb/valprint.c:1133
#8 0x20caa8c in common_val_print_checked(value*, ui_file*, int, value_print_options const*, language_defn const*) gdb/valprint.c:1182
#9 0x196c524 in print_variable_and_value(char const*, symbol*, frame_info_ptr, ui_file*, int) gdb/printcmd.c:2355
#10 0x1d99ca0 in print_variable_and_value_data::operator()(char const*, symbol*) gdb/stack.c:2308
#11 0x1dabca0 in gdb::function_view<void (char const*, symbol*)>::bind<print_variable_and_value_data>(print_variable_and_value_data&)::{lambda(gdb::fv_detail::erased_callable, char const*, symbol*)#1}::operator()(gdb::fv_detail::erased_callable, char const*, symbol*) const gdb/../gdbsupport/function-view.h:305
#12 0x1dabd14 in gdb::function_view<void (char const*, symbol*)>::bind<print_variable_and_value_data>(print_variable_and_value_data&)::{lambda(gdb::fv_detail::erased_callable, char const*, symbol*)#1}::_FUN(gdb::fv_detail::erased_callable, char const*, symbol*) gdb/../gdbsupport/function-view.h:299
#13 0x1dab34c in gdb::function_view<void (char const*, symbol*)>::operator()(char const*, symbol*) const gdb/../gdbsupport/function-view.h:289
#14 0x1d9963c in iterate_over_block_locals gdb/stack.c:2240
#15 0x1d99790 in iterate_over_block_local_vars(block const*, gdb::function_view<void (char const*, symbol*)>) gdb/stack.c:2259
#16 0x1d9a598 in print_frame_local_vars gdb/stack.c:2380
#17 0x1d9afac in info_locals_command(char const*, int) gdb/stack.c:2458
#18 0xfd7b30 in do_simple_func gdb/cli/cli-decode.c:95
#19 0xfe5a2c in cmd_func(cmd_list_element*, char const*, int) gdb/cli/cli-decode.c:2735
#20 0x1f03790 in execute_command(char const*, int) gdb/top.c:575
#21 0x1384080 in command_handler(char const*) gdb/event-top.c:566
#22 0x1384e2c in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) gdb/event-top.c:802
#23 0x1f731e4 in tui_command_line_handler gdb/tui/tui-interp.c:104
#24 0x1382a58 in gdb_rl_callback_handler gdb/event-top.c:259
#25 0x21dbb80 in rl_callback_read_char readline/readline/callback.c:290
#26 0x1382510 in gdb_rl_callback_read_char_wrapper_noexcept gdb/event-top.c:195
#27 0x138277c in gdb_rl_callback_read_char_wrapper gdb/event-top.c:234
#28 0x1fe9b40 in stdin_event_handler gdb/ui.c:155
#29 0x35ff1bc in handle_file_event gdbsupport/event-loop.cc:573
SUMMARY: AddressSanitizer: heap-buffer-overflow (/lib64/libasan.so.8+0x6da18) in memmove
...
The error happens when trying to print either variable y or y2:
...
type Variable_Record (A : Boolean := True) is record
case A is
when True =>
B : Integer;
when False =>
C : Float;
D : Integer;
end case;
end record;
Y : Variable_Record := (A => True, B => 1);
Y2 : Variable_Record := (A => False, C => 1.0, D => 2);
...
when the variables are uninitialized.
The error happens only when printing the entire variable:
...
(gdb) p y.a
$2 = 216
(gdb) p y.b
There is no member named b.
(gdb) p y.c
$3 = 9.18340949e-41
(gdb) p y.d
$4 = 1
(gdb) p y
<AddressSanitizer: heap-buffer-overflow>
...
The error happens as follows:
- field a functions as discriminant, choosing either the b, or c+d variant.
- when y.a happens to be set to 216, as above, gdb interprets this as the
variable having the c+d variant (which is why trying to print y.b fails).
- when printing y, gdb allocates a value, copies the bytes into it from the
target, and then prints the value.
- gdb allocates the value using the type size, which is 8. It's 8 because
that's what the DW_AT_byte_size indicates. Note that for valid values of a,
it gives correct results: if a is 0 (c+d variant), size is 12, if a is 1
(b variant), size is 8.
- gdb tries to print field d, which is at an 8 byte offset, and that results
in a out-of-bounds access for the allocated 8-byte value.
Fix this by handling this case in value::contents_copy_raw, such that we have:
...
(gdb) p y
$1 = (a => 24, c => 9.18340949e-41,
d => <error reading variable: access outside bounds of object>)
...
An alternative (additional) fix could be this: in compute_variant_fields_inner
gdb reads the discriminant y.a to decide which variant is active. It would be
nice to detect that the value (y.a == 24) is not a valid Boolean, and give up
on choosing a variant altoghether. However, the situation regarding the
internal type CODE_TYPE_BOOL is currently ambiguous (see PR31282) and it's not
possible to reliably decide what valid values are.
The test-case source file gdb.ada/uninitialized-variable-record/parse.adb is
a reduced version of gdb.ada/uninitialized_vars/parse.adb, so it copies the
copyright years.
Note that the test-case needs gcc-12 or newer, it's unsupported for older gcc
versions. [ So, it would be nice to rewrite it into a dwarf assembly
test-case. ]
The test-case loops over all languages. This is inherited from an earlier
attempt to fix this, which had language-specific fixes (in print_field_values,
cp_print_value_fields, pascal_object_print_value_fields and
f_language::value_print_inner). I've left this in, but I suppose it's not
strictly necessary anymore.
Tested on x86_64-linux.
PR exp/31258
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31258
|
|
|
|
|
|
|
|
Add -plugin-save-temps to store plugin intermediate files permanently.
It can be used to exam the final input object files generated from IR
inputs.
* NEWS: Mention -plugin-save-temps.
* ld.h (ld_config_type): Add plugin_save_temps.
* ld.texi: Document -plugin-save-temps.
* ldlex.h (option_values): Add OPTION_PLUGIN_SAVE_TEMPS.
* lexsup.c (ld_options): Add -plugin-save-temps.
(parse_args): Handle OPTION_PLUGIN_SAVE_TEMPS.
* plugin.c (plugin_call_cleanup): Don't call plugin
cleanup_handler for -plugin-save-temps.
|
|
The assertion in nios2_elf32_install_imm16 triggers when the PLT is
twice the maximum allowable size for a branch from PLTn to reach
.PLTresolve, and on no other call to nios2_elf32_install_imm16. That
makes the assertion completely useless. We can handle a PIC PLT
exceeding 0x8000 in size by bouncing branches that won't reach through
previous branches.
PR 27597
* elf32-nios2.c (nios2_elf32_install_imm16): Delete BFD_ASSERT.
(nios2_build_one_stub): Don't bother masking value passed to
nios2_elf32_install_imm16.
(nios2_elf32_finish_dynamic_symbol): Likewise. Handle overflow
of PLTn branch to .PLTresolve by bouncing through prior branches.
|
|
the documentation
|
|
While necessary on the legacy encodings, the EVEX ones don't need it.
Even more so when they're available for 64-bit mode only, when the
legacy encodings have the attribute only for correctly handling things
in 16-bit mode.
|
|
Several years ago it was decided that SSE2AVX templates should not be
sensitive to -mvexwig= (upon my suggestion to consistently make all
sensitive as long as they don't require a specific setting of VEX.W).
Adjust the four that still are, switching to use of Vex128 at the same
time.
|
|
While e20298da05f2 ("Remove redundant Byte, Word, Dword and Qword from
insn templates") did so for Byte/Word/Dword/Qword, the same kind of
redundancy was left in place for a few 128-bit SIMD operands.
|
|
Having multiple tests with the same name is confusing.
|
|
|
|
Display -msse-check= default as none for "as --help" since its default
is none, not warning.
PR gas/31389
* config/tc-i386.c (md_show_usage): Change -msse-check= default
to none.
|
|
Like 10e7c0457cb7 but for elf32-s390.c
* elf32-s390.c (elf_s390_adjust_dynamic_symbol): Use
UNDEFWEAK_NO_DYNAMIC_RELOC.
(allocate_dynrelocs): Likewise.
(elf_s390_relocate_section): Check resolved_to_zero.
(elf_s390_finish_dynamic_symbol): Don't generate runtime reloc if
UNDEFWEAK_NO_DYNAMIC_RELOC.
|
|
I noticed that basic_lookup_transparent_type calls two different
functions that both proceed to create a lookup_name_info. It's more
efficient to create this object in the outermost layer possible.
Making this change required a few related changes, resulting in this
patch.
There are still more changes of this sort that could be made.
Regression tested on x86-64 Fedora 38.
|
|
Albeit not being a currently valid BPF instruction, callx is generated
by both clang and GCC when BPF programs are compiled unoptimized.
Until now, GCC would emit it only whe using the experimental
compiler-testing cpu version xbpf, whereas clang would emit it from
v1. This patch makes GAS to accept callx also starting with cpu v1.
opcodes/ChangeLog
* bpf-opc.c: Move callx into the v1 BPF CPU variant.
gas/ChangeLog
* testsuite/gas/bpf/indcall-1-pseudoc.d: Do not select xbpf cpu
version.
* testsuite/gas/bpf/indcall-1.d: Likewise.
|
|
* symbols.c (S_IS_FUNCTION, S_IS_EXTERNAL, S_IS_WEAK),
(S_IS_WEAKREFR, S_IS_WEAKREFD, S_IS_COMMON, S_IS_DEFINED),
(S_FORCE_RELOC, S_IS_DEBUG, S_IS_LOCAL, S_IS_STABD),
(symbol_previous, symbol_next, symbol_X_add_number),
(symbol_get_frag, symbol_used_p, symbol_used_in_reloc_p),
(symbol_mri_common_p, symbol_written_p, symbol_removed_p),
(symbol_resolved_p, symbol_resolving_p, symbol_section_p),
(symbol_equated_p, symbol_equated_reloc_p, symbol_constant_p),
(symbol_shadow_p, symbol_same_p): Constify sym args.
* symbols.h: Update prototypes.
|
|
Making a bfd_final_link failure noisy requires testsuite changes.
|
|
PR 28448
* plugin.c (add_symbols): bfd_alloc memory for symptrs. Check
bfd_make_empty_symbol return.
|
|
I didn't examine ld testsuite logs properly after cf95b909e2c2.
Replacing one of the "return false" with BFD_ASSERT in
finish_dynamic_symbol was wrong as it causes segmentation faults on
testcases expected to fail. Revert those changes and instead make
a bfd_final_link failure noisy.
|
|
Signed-off-by: Samuel Tardieu <sam@rfc1149.net>
Approved-by: Eli Zaretskii <eliz@gnu.org>
Copyright-paperwork-exempt: yes
|
|
Pathological cases of dwarf info with overlapping duplicate memory
ranges can cause splitting of trie leaf nodes, which in the worst case
will cause memory to increase without bounds.
PR 29785
* dwarf2.c (insert_arange_in_trie): Don't split leaf nodes
unless that reduces number of elements in at least one node.
|
|
This patch exposes the symbol "resolving" flag for use in
i386_intel_simplify, not only preventing infinite recursion on the
testcase in the PR but also more complicated cases like:
.intel_syntax
b = a
a = b
mov eax, [a]
PR 30308
* symbols.c (symbol_mark_resolving, symbol_clear_resolving),
(symbol_resolving_p): New functions.
* symbols.h: Declare them.
* config/tc-i386-intel.c (i386_intel_simplify): Delete forward
declaration. Formatting.
(i386_intel_simplify_symbol): Use resolving flag to prevent
infinite recursion.
|
|
Returning false from elf_backend_finish_dynamic_symbol will not result
in an error being printed unless bfd_error is set but will result in
the linker exiting with a non-zero status. If just bfd_error is set
then a generic "final link failed" will result, which doesn't help a
user much. So elf_backend_finish_dynamic_symbol should print its own
error message whenever returning false, or use BFD_ASSERT or abort to
print assertion failures for conditions that shouldn't occur.
This patch does that, and removes unnecessary "htab != NULL" tests in
elf_backend_finish_dynamic_symbol. Such tests aren't needed in a
function only called via elf_backend_data.
|
|
|
|
When running test-case gdb.dap/eof.exp, we're likely to get a coredump due to
a segfault in new_threadstate.
At the point of the core dump, the gdb main thread looks like:
...
(gdb) bt
#0 0x0000fffee30d2280 in __pthread_kill_implementation () from /lib64/libc.so.6
#1 0x0000fffee3085800 [PAC] in raise () from /lib64/libc.so.6
#2 0x00000000007b03e8 [PAC] in handle_fatal_signal (sig=11)
at gdb/event-top.c:926
#3 0x00000000007b0470 in handle_sigsegv (sig=11)
at gdb/event-top.c:976
#4 <signal handler called>
#5 0x0000fffee3a4db14 in new_threadstate () from /lib64/libpython3.12.so.1.0
#6 0x0000fffee3ab0548 [PAC] in PyGILState_Ensure () from /lib64/libpython3.12.so.1.0
#7 0x0000000000a6d034 [PAC] in gdbpy_gil::gdbpy_gil (this=0xffffcb279738)
at gdb/python/python-internal.h:787
#8 0x0000000000ab87ac in gdbpy_event::~gdbpy_event (this=0xfffea8001ee0,
__in_chrg=<optimized out>) at gdb/python/python.c:1051
#9 0x0000000000ab9460 in std::_Function_base::_Base_manager<...>::_M_destroy
(__victim=...) at /usr/include/c++/13/bits/std_function.h:175
#10 0x0000000000ab92dc in std::_Function_base::_Base_manager<...>::_M_manager
(__dest=..., __source=..., __op=std::__destroy_functor)
at /usr/include/c++/13/bits/std_function.h:203
#11 0x0000000000ab8f14 in std::_Function_handler<...>::_M_manager(...) (...)
at /usr/include/c++/13/bits/std_function.h:282
#12 0x000000000042dd9c in std::_Function_base::~_Function_base (this=0xfffea8001c10,
__in_chrg=<optimized out>) at /usr/include/c++/13/bits/std_function.h:244
#13 0x000000000042e654 in std::function<void ()>::~function() (this=0xfffea8001c10,
__in_chrg=<optimized out>) at /usr/include/c++/13/bits/std_function.h:334
#14 0x0000000000b68e60 in std::_Destroy<std::function<void ()> >(...) (...)
at /usr/include/c++/13/bits/stl_construct.h:151
#15 0x0000000000b68cd0 in std::_Destroy_aux<false>::__destroy<...>(...) (...)
at /usr/include/c++/13/bits/stl_construct.h:163
#16 0x0000000000b689d8 in std::_Destroy<...>(...) (...)
at /usr/include/c++/13/bits/stl_construct.h:196
#17 0x0000000000b68414 in std::_Destroy<...>(...) (...)
at /usr/include/c++/13/bits/alloc_traits.h:948
#18 std::vector<...>::~vector() (this=0x2a183c8 <runnables>)
at /usr/include/c++/13/bits/stl_vector.h:732
#19 0x0000fffee3088370 in __run_exit_handlers () from /lib64/libc.so.6
#20 0x0000fffee3088450 [PAC] in exit () from /lib64/libc.so.6
#21 0x0000000000c95600 [PAC] in quit_force (exit_arg=0x0, from_tty=0)
at gdb/top.c:1822
#22 0x0000000000609140 in quit_command (args=0x0, from_tty=0)
at gdb/cli/cli-cmds.c:508
#23 0x0000000000c926a4 in quit_cover () at gdb/top.c:300
#24 0x00000000007b09d4 in async_disconnect (arg=0x0)
at gdb/event-top.c:1230
#25 0x0000000000548acc in invoke_async_signal_handlers ()
at gdb/async-event.c:234
#26 0x000000000157d2d4 in gdb_do_one_event (mstimeout=-1)
at gdbsupport/event-loop.cc:199
#27 0x0000000000943a84 in start_event_loop () at gdb/main.c:401
#28 0x0000000000943bfc in captured_command_loop () at gdb/main.c:465
#29 0x000000000094567c in captured_main (data=0xffffcb279d08)
at gdb/main.c:1335
#30 0x0000000000945700 in gdb_main (args=0xffffcb279d08)
at gdb/main.c:1354
#31 0x0000000000423ab4 in main (argc=14, argv=0xffffcb279e98)
at gdb/gdb.c:39
...
The direct cause of the segfault is calling PyGILState_Ensure after
calling Py_Finalize.
AFAICT the problem is a race between the gdb main thread and DAP's JSON writer
thread.
On one side, we have the following events:
- DAP's JSON reader thread reads an EOF, and lets DAP's main thread known
by writing None into read_queue
- DAP's main thread lets DAP's JSON writer thread known by writing None into
write_queue
- DAP's JSON writer thread sees the None in its queue, and calls
send_gdb("quit")
- a corresponding gdbpy_event is deposited in the runnables vector, to be
run by the gdb main thread
On the other side, we have the following events:
- the gdb main thread receives a SIGHUP
- the corresponding handler calls quit_force, which calls do_final_cleanups
- one of the final cleanups is finalize_python, which calls Py_Finalize
- quit_force calls exit, which triggers the exit handlers
- one of the exit handlers is the destructor of the runnables vector
- destruction of the vector triggers destruction of the remaining element
- the remaining element is a gdbpy_event, and the destructor (indirectly)
calls PyGILState_Ensure
It's good to note that both events (EOF and SIGHUP) are caused by this line in
the test-case:
...
catch "close -i $gdb_spawn_id"
...
where "expect close" closes the stdin and stdout file descriptors, which
causes the SIGHUP to be send.
So, for the system I'm running this on, the send_gdb("quit") is actually not
needed.
I'm not sure if we support any systems where it's actually needed.
Fix this by removing the send_gdb("quit").
Tested on aarch64-linux.
PR dap/31306
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31306
|
|
Reformat amd64_dwarf_reg_to_regnum:
@@ -254,8 +254,7 @@ amd64_dwarf_reg_to_regnum (struct gdbarch *gdbarch, int reg)
if (reg >= 0 && reg < amd64_dwarf_regmap_len)
regnum = amd64_dwarf_regmap[reg];
- if (ymm0_regnum >= 0
- && i386_xmm_regnum_p (gdbarch, regnum))
+ if (ymm0_regnum >= 0 && i386_xmm_regnum_p (gdbarch, regnum))
regnum += ymm0_regnum - I387_XMM0_REGNUM (tdep);
to remove the misaligned line.
|
|
This changes the global 'warning_hook' to use the warning_hook_handler
typedef in its definition. This makes it a little easier to change
the type, should that be needed.
|
|
DBNZ instruction decrements its source register operand, and if
the result is non-zero it branches to the location defined by a signed
half-word displacement operand.
DBNZ instruction is in BRANCH class as other branch instrucitons
like B, Bcc, etc. However, DBNZ is the only branch instruction
that stores a branch offset in the second operand. Thus it must
be placed in a distinct class and treated differently.
For example, current logic of arc_insn_get_branch_target in GDB
assumes that a branch offset is always stored in the first operand
for BRANCH class and it's wrong for DBNZ.
include/ChangeLog:
2024-02-14 Yuriy Kolerov <ykolerov@synopsys.com>
* opcode/arc.h (enum insn_class_t): Add DBNZ class.
opcodes/ChangeLog:
2024-02-14 Yuriy Kolerov <ykolerov@synopsys.com>
* arc-tbl.h (dbnz): Use "DBNZ" class.
* arc-dis.c (arc_opcode_to_insn_type): Handle "DBNZ" class.
gas/ChangeLog:
2024-02-14 Yuriy Kolerov <ykolerov@synopsys.com>
* config/tc-arc.c (is_br_jmp_insn_p): Add check against "DBNZ".
|
|
With gdb.dap/sources.exp on aarch64-linux, I'm running into:
...
{"request_seq": 3, "type": "response", "command": "loadedSources", \
"success": false, "message": "notStopped", "seq": 7}Content-Length: 92^M
^M
{"type": "event", "event": "thread", \
"body": {"reason": "started", "threadId": 1}, \
"seq": 8}FAIL: gdb.dap/sources.exp: loadedSources success
ERROR: tcl error sourcing gdb.dap/sources.exp.
ERROR: tcl error code TCL LOOKUP DICT body
ERROR: key "body" not known in dictionary
while executing
"dict get [lindex $obj 0] body sources"
...
These are the same type of tcl error and FAIL I just fixed for a later
request in the same test-case.
Fix this by:
- moving the wait-for-stop to before the loadedSources request to fix the
FAIL, and
- checking for $obj == "" to fix the tcl error.
Also make the code a bit less indented and more readable by wrapping the tests
in a proc, allowing the use of return to bail out, while still running
dap_shutdown afterwards.
Approved-By: Tom Tromey <tom@tromey.com>
Tested on aarch64-linux.
|
|
|
|
Breaking a TCL string to several lines leads to adding of extra
symbols to the resulting expect string. In turn, this leads to
failing of all test cases in gdb.arch/arc-disassembler-options.exp
testsuite. It's necessary to use multi_line function in such
cases.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
With test-case gdb.dap/sources.exp, I run into:
...
{"request_seq": 4, "type": "response", "command": "source", \
"success": false, "message": "notStopped", \
"seq": 11}FAIL: gdb.dap/sources.exp: get source success
...
The fail happens because the request races with the stopping at main as
requested by:
...
if {[dap_launch $testfile stop_at_main 1] == ""} {
...
Fix this by waiting for the stop, in the same way that is done in other
test-cases that use stop_at_main.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR testsuite/31374
https://sourceware.org/bugzilla/show_bug.cgi?id=31374
|
|
Added support for simulation of compressed integer instruction set ("c").
Added test file sim/testsuite/riscv/c-ext.s to test compressed instructions.
The compressed instructions are available for models implementing C extension.
Such as RV32IC, RV64IC, RV32GC, RV64GC etc.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
With test-case gdb.dap/sources.exp, I run into:
...
{"request_seq": 4, "type": "response", "command": "source", \
"success": false, "message": "notStopped", \
"seq": 11}FAIL: gdb.dap/sources.exp: get source success
ERROR: tcl error sourcing gdb.dap/sources.exp.
ERROR: key "body" not known in dictionary
...
The FAIL has been filed as PR dap/31374.
The ERROR happens because after the FAIL, dap_check_request_and_response
returns "", and the test-case doesn't check for that.
Fix this by checking for $obj != "" in the test-case.
Tested on x86_64-linux.
|
|
When running test-case gdb.reverse/func-map-to-same-line.exp on arm-linux with
target board unix/-mthumb, we run into:
...
(gdb) reverse-step
func2 () at func-map-to-same-line.c:26
26 {
(gdb) FAIL: gdb.reverse/func-map-to-same-line.exp: \
column_info_flag=column-info: step-test: reverse-step into func2
...
The FAIL is caused by incorrect recording of this insn:
...
4f6: f85d 7b04 ldr.w r7, [sp], #4
...
The insn updates the sp, but we don't record this:
...
$ gdb -q -batch func-map-to-same-line \
-ex "b *func2+8" \
-ex run \
-ex record \
-ex "set debug record 2" \
-ex stepi
Breakpoint 1 at 0x4f6: file func-map-to-same-line.c, line 27.
Breakpoint 1, 0xaaaaa4f6 in func2 () at func-map-to-same-line.c:27
27 } /* END FUNC2 */
Process record: arm_process_record addr = 0xaaaaa4f6
Process record: add register num = 15 to record list.
Process record: record_full_arch_list_add 0xabc6c460.
Process record: add register num = 7 to record list.
Process record: record_full_arch_list_add 0xabc3b868.
Process record: add register num = 25 to record list.
...
[ Note that sp is r13, and we see here only r15 (pc), r7, and r25 (ps). ]
The problem is that the specific insn, an LDR(immediate) T4, is not handled in
thumb2_record_ld_word.
Fix this by detecting the insn in thumb2_record_ld_word, and recording the
updated base register.
Tested on arm-linux.
Reported-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Approved-By: Luis Machado <luis.machado@arm.com>
PR tdep/31278
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31278
|
|
|
|
gdb likes to control its own output; for example, this is important
for gdb's pager, and for logging. While BFD provides a way to
intercept error output, via bfd_set_error_handler, it turns out to be
difficult for this function to truly generate the desired output in a
gdb-friendly way -- the error handler is expected to implement some
BFD printf format extensions.
This patch introduces a new function that an error handler can use to
format the text. This way, gdb can set the error handler and arrange
for the output to be displayed as it likes.
* bfd.c (bfd_print_callback): Rename from print_func. Move into
comment.
(_bfd_doprnt): Update.
(bfd_print_error): New function.
(error_handler_fprintf, error_handler_sprintf): Use
bfd_print_error.
* bfd-in2.h: Rebuild.
|
|
I noticed that _bfd_doprnt can unconditionally call fputc. However,
when called from error_handler_sprintf, this will likely result in a
crash, as the stream argument does not actually point to a FILE.
* bfd.c (_bfd_doprnt): Do not call fputc.
|
|
Commit 433ae2c2458 ("[gdb/dap] Catch and log exceptions in dap threads") made
some changes to gdb/python/lib/gdb/dap/startup.py.
Re-format it with black.
|
|
When running test-case gdb.dap/eof.exp, it occasionally coredumps.
The thread triggering the coredump is:
...
#0 0x0000ffff42bb2280 in __pthread_kill_implementation () from /lib64/libc.so.6
#1 0x0000ffff42b65800 [PAC] in raise () from /lib64/libc.so.6
#2 0x00000000007b03e8 [PAC] in handle_fatal_signal (sig=11)
at gdb/event-top.c:926
#3 0x00000000007b0470 in handle_sigsegv (sig=11)
at gdb/event-top.c:976
#4 <signal handler called>
#5 0x0000000000606080 in cli_ui_out::do_message (this=0xffff2f7ed728, style=...,
format=0xffff0c002af1 "%s", args=...) at gdb/cli-out.c:232
#6 0x0000000000ce6358 in ui_out::call_do_message (this=0xffff2f7ed728, style=...,
format=0xffff0c002af1 "%s") at gdb/ui-out.c:584
#7 0x0000000000ce6610 in ui_out::vmessage (this=0xffff2f7ed728, in_style=...,
format=0x16f93ea "", args=...) at gdb/ui-out.c:621
#8 0x0000000000ce3a9c in ui_file::vprintf (this=0xfffffbea1b18, ...)
at gdb/ui-file.c:74
#9 0x0000000000d2b148 in gdb_vprintf (stream=0xfffffbea1b18, format=0x16f93e8 "%s",
args=...) at gdb/utils.c:1898
#10 0x0000000000d2b23c in gdb_printf (stream=0xfffffbea1b18, format=0x16f93e8 "%s")
at gdb/utils.c:1913
#11 0x0000000000ab5208 in gdbpy_write (self=0x33fe35d0, args=0x342ec280, kw=0x345c08b0)
at gdb/python/python.c:1464
#12 0x0000ffff434acedc in cfunction_call () from /lib64/libpython3.12.so.1.0
#13 0x0000ffff4347c500 [PAC] in _PyObject_MakeTpCall ()
from /lib64/libpython3.12.so.1.0
#14 0x0000ffff43488b64 [PAC] in _PyEval_EvalFrameDefault ()
from /lib64/libpython3.12.so.1.0
#15 0x0000ffff434d8cd0 [PAC] in method_vectorcall () from /lib64/libpython3.12.so.1.0
#16 0x0000ffff434b9824 [PAC] in PyObject_CallOneArg () from /lib64/libpython3.12.so.1.0
#17 0x0000ffff43557674 [PAC] in PyFile_WriteObject () from /lib64/libpython3.12.so.1.0
#18 0x0000ffff435577a0 [PAC] in PyFile_WriteString () from /lib64/libpython3.12.so.1.0
#19 0x0000ffff43465354 [PAC] in thread_excepthook () from /lib64/libpython3.12.so.1.0
#20 0x0000ffff434ac6e0 [PAC] in cfunction_vectorcall_O ()
from /lib64/libpython3.12.so.1.0
#21 0x0000ffff434a32d8 [PAC] in PyObject_Vectorcall () from /lib64/libpython3.12.so.1.0
#22 0x0000ffff43488b64 [PAC] in _PyEval_EvalFrameDefault ()
from /lib64/libpython3.12.so.1.0
#23 0x0000ffff434d8d88 [PAC] in method_vectorcall () from /lib64/libpython3.12.so.1.0
#24 0x0000ffff435e0ef4 [PAC] in thread_run () from /lib64/libpython3.12.so.1.0
#25 0x0000ffff43591ec0 [PAC] in pythread_wrapper () from /lib64/libpython3.12.so.1.0
#26 0x0000ffff42bb0584 [PAC] in start_thread () from /lib64/libc.so.6
#27 0x0000ffff42c1fd4c [PAC] in thread_start () from /lib64/libc.so.6
...
The direct cause for the coredump seems to be that cli_ui_out::do_message
is trying to write to a stream variable which does not look sound:
...
(gdb) p *stream
$8 = {_vptr.ui_file = 0x0, m_applied_style = {m_foreground = {m_simple = true, {
m_value = 0, {m_red = 0 '\000', m_green = 0 '\000', m_blue = 0 '\000'}}},
m_background = {m_simple = 32, {m_value = 65535, {m_red = 255 '\377',
m_green = 255 '\377', m_blue = 0 '\000'}}},
m_intensity = (unknown: 0x438fe710), m_reverse = 255}}
...
The string that is being printed is:
...
(gdb) p str
$9 = "Exception in thread "
...
so AFAICT this is a DAP thread running into an exception and trying to print
it.
If we look at the state of gdb's main thread, we have:
...
#0 0x0000ffff42bac914 in __futex_abstimed_wait_cancelable64 () from /lib64/libc.so.6
#1 0x0000ffff42bafb44 [PAC] in pthread_cond_timedwait@@GLIBC_2.17 ()
from /lib64/libc.so.6
#2 0x0000ffff43466e9c [PAC] in take_gil () from /lib64/libpython3.12.so.1.0
#3 0x0000ffff43484fe0 [PAC] in PyEval_RestoreThread ()
from /lib64/libpython3.12.so.1.0
#4 0x0000000000ab8698 [PAC] in gdbpy_allow_threads::~gdbpy_allow_threads (
this=0xfffffbea1cf8, __in_chrg=<optimized out>)
at gdb/python/python-internal.h:769
#5 0x0000000000ab2fec in execute_gdb_command (self=0x33fe35d0, args=0x34297b60,
kw=0x34553d20) at gdb/python/python.c:681
#6 0x0000ffff434acedc in cfunction_call () from /lib64/libpython3.12.so.1.0
#7 0x0000ffff4347c500 [PAC] in _PyObject_MakeTpCall ()
from /lib64/libpython3.12.so.1.0
#8 0x0000ffff43488b64 [PAC] in _PyEval_EvalFrameDefault ()
from /lib64/libpython3.12.so.1.0
#9 0x0000ffff4353bce8 [PAC] in _PyObject_VectorcallTstate.lto_priv.3 ()
from /lib64/libpython3.12.so.1.0
#10 0x0000000000ab87fc [PAC] in gdbpy_event::operator() (this=0xffff14005900)
at gdb/python/python.c:1061
#11 0x0000000000ab93e8 in std::__invoke_impl<void, gdbpy_event&> (__f=...)
at /usr/include/c++/13/bits/invoke.h:61
#12 0x0000000000ab9204 in std::__invoke_r<void, gdbpy_event&> (__fn=...)
at /usr/include/c++/13/bits/invoke.h:111
#13 0x0000000000ab8e90 in std::_Function_handler<..>::_M_invoke(...) (...)
at /usr/include/c++/13/bits/std_function.h:290
#14 0x000000000062e0d0 in std::function<void ()>::operator()() const (
this=0xffff14005830) at /usr/include/c++/13/bits/std_function.h:591
#15 0x0000000000b67f14 in run_events (error=0, client_data=0x0)
at gdb/run-on-main-thread.c:76
#16 0x000000000157e290 in handle_file_event (file_ptr=0x33dae3a0, ready_mask=1)
at gdbsupport/event-loop.cc:573
#17 0x000000000157e760 in gdb_wait_for_event (block=1)
at gdbsupport/event-loop.cc:694
#18 0x000000000157d464 in gdb_do_one_event (mstimeout=-1)
at gdbsupport/event-loop.cc:264
#19 0x0000000000943a84 in start_event_loop () at gdb/main.c:401
#20 0x0000000000943bfc in captured_command_loop () at gdb/main.c:465
#21 0x000000000094567c in captured_main (data=0xfffffbea23e8)
at gdb/main.c:1335
#22 0x0000000000945700 in gdb_main (args=0xfffffbea23e8)
at gdb/main.c:1354
#23 0x0000000000423ab4 in main (argc=14, argv=0xfffffbea2578)
at gdb/gdb.c:39
...
AFAIU, there's a race between the two threads on gdb_stderr:
- the DAP thread samples the gdb_stderr value, and uses it a bit later to
print to
- the gdb main thread changes the gdb_stderr value forth and back,
using a temporary value for string capture purposes
The non-sound stream value is caused by gdb_stderr being sampled while
pointing to a str_file object, and used once the str_file object is already
destroyed.
The error here is that the DAP thread attempts to print to gdb_stderr.
Fix this by adding a thread_wrapper that:
- catches all exceptions and logs them to dap.log, and
- while we're at it, logs when exiting
and using the thread_wrapper for each DAP thread.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Co-workers at AdaCore pointed out that gdb incorrectly implements the
DAP launch and configurationDone requests. It's somewhat strange to
me, but the spec does in fact say that configuration requests should
occur before the executable is known to gdb. This was clarified in
this bug report against the spec:
https://github.com/microsoft/debug-adapter-protocol/issues/452
Fixing 'launch' to start the inferior was straightforward, but this
then required some changes to how breakpoints are handled. In
particular, now gdb will emit the "pending" reason on a breakpoint,
and will suppress breakpoint events during breakpoint setting.
|
|
Kévin pointed out that suppress_new_breakpoint_event would do the
wrong thing if it happened to be used reentrantly. While I don't
think this can happen, it's also easy and clearly better to make it
robust.
|
|
This changes the test suite to export dap_initialize.
|
|
New year, new black version.
Change-Id: I664601e6dd255358063e15f6d73bc5f02c8f2b9d
|
|
binutils * readelf.c (get_segment_type): Handle PT_OPENBSD_SYSCALLS segment type.
include * elf/common.h (PT_OPENBSD_SYSCALLS): Define.
|
|
The function rs6000_epilogue_frame_cache assumes the LR and gprs have been
restored. In fact register r31 and the link register, lr, may not have
been restored yet. This patch adds support to store the lr and gpr
register unrolling rules in the cache. The LR and GPR values can now be
unrolled correctly.
Patch fixes all 10 regresion test failures for the unwind-on-each-insn.exp.
|
|
packet_check_result currently returns an packet_result enum.
If GDB will recieve an error in a format E.errtext, which
is possible for some q packets, such errtext is lost if
treated by packet_check_result.
Introduce a new structure which bundles enum packet_result
with possible error message or error code returned by
the GDBserver.
I plan to make more GDBserver response checking functions to use
packet_check_result to make remote.c code more consistent.
This will also allow to use E.errtext more in the future.
Beside adding the unit test, I tested this by modifying
store_registers_using_G function to get an error message:
[remote] Sending packet: $GG00000000 ...
gdbserver: Wrong sized register packet (expected 1792 bytes, got 1793)
gdbserver: Invalid hex digit 71
Killing process(es): 1104002
[remote] Packet received: E01
Could not write registers; remote failure reply '01'
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
|
|
|
|
If you try to call Frame.static_link for a frame without debug info,
gdb crashes:
```
Temporary breakpoint 1, 0x000000013f821650 in main ()
(gdb) py print(gdb.selected_frame().static_link())
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
```
The problem was a missing check if get_frame_block returns nullptr
inside frame_follow_static_link.
With this, it works:
```
Temporary breakpoint 1, 0x000000013f941650 in main ()
(gdb) py print(gdb.selected_frame().static_link())
None
```
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31366
Approved-By: Tom Tromey <tom@tromey.com>
|
