aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-05-11Add LDPT_REGISTER_CLAIM_FILE_HOOK_V2 linker plugin hook [GCC PR109128]Joseph Myers28-12/+102
This is one part of the fix for GCC PR109128, along with a corresponding GCC change. Without this patch, what happens in the linker, when an unused object in a .a file has offload data, is that elf_link_is_defined_archive_symbol calls bfd_link_plugin_object_p, which ends up calling the plugin's claim_file_handler, which then records the object as one with offload data. That is, the linker never decides to use the object in the first place, but use of this _p interface (called as part of trying to decide whether to use the object) results in the plugin deciding to use its offload data (and a consequent mismatch in the offload data present at runtime). The new hook allows the linker plugin to distinguish calls to claim_file_handler that know the object is being used by the linker (from ldmain.c:add_archive_element), from calls that don't know it's being used by the linker (from elf_link_is_defined_archive_symbol); in the latter case, the plugin should avoid recording the object as one with offload data. bfd/ * plugin.c (struct plugin_list_entry): Add claim_file_v2. (register_claim_file_v2): New. (try_load_plugin): Use LDPT_REGISTER_CLAIM_FILE_HOOK_V2. (ld_plugin_object_p): Take second argument. (bfd_link_plugin_object_p): Update call to ld_plugin_object_p. (register_ld_plugin_object_p): Update argument prototype. (bfd_plugin_object_p): Update call to ld_plugin_object_p. * plugin.h (register_ld_plugin_object_p): Update argument prototype. include/ * plugin.api.h (ld_plugin_claim_file_handler_v2) (ld_plugin_register_claim_file_v2) (LDPT_REGISTER_CLAIM_FILE_HOOK_V2): New. (struct ld_plugin_tv): Add tv_register_claim_file_v2. ld/ * plugin.c (struct plugin): Add claim_file_handler_v2. (LDPT_REGISTER_CLAIM_FILE_HOOK_V2): New. (plugin_object_p): Add second argument. Update call to plugin_call_claim_file. (register_claim_file_v2): New. (set_tv_header): Handle LDPT_REGISTER_CLAIM_FILE_HOOK_V2. (plugin_call_claim_file): Add argument known_used. (plugin_maybe_claim): Update call to plugin_object_p. * testplug.c, testplug2.c, testplug3.c, testplug4.c: Handle LDPT_REGISTER_CLAIM_FILE_HOOK_V2. * testsuite/ld-plugin/plugin-1.d, testsuite/ld-plugin/plugin-10.d, testsuite/ld-plugin/plugin-11.d, testsuite/ld-plugin/plugin-13.d, testsuite/ld-plugin/plugin-14.d, testsuite/ld-plugin/plugin-15.d, testsuite/ld-plugin/plugin-16.d, testsuite/ld-plugin/plugin-17.d, testsuite/ld-plugin/plugin-18.d, testsuite/ld-plugin/plugin-19.d, testsuite/ld-plugin/plugin-2.d, testsuite/ld-plugin/plugin-26.d, testsuite/ld-plugin/plugin-3.d, testsuite/ld-plugin/plugin-30.d, testsuite/ld-plugin/plugin-4.d, testsuite/ld-plugin/plugin-5.d, testsuite/ld-plugin/plugin-6.d, testsuite/ld-plugin/plugin-7.d, testsuite/ld-plugin/plugin-8.d, testsuite/ld-plugin/plugin-9.d: Update test expectations.
2023-05-11Automatic date update in version.inGDB Administrator1-1/+1
2023-05-10[gdb/tui] Fix tui compact-source a bit moreTom de Vries2-17/+29
Andrew pointed out that the behaviour as tested in gdb.tui/compact-source.exp is incorrect: ... 0 +-compact-source.c--------------------------------------------------------+ 1 |___3_{ | 2 |___4_ return 0; | 3 |___5_} | 4 |___6_ | 5 |___7_ | 6 |___8_ | 7 |___9_ | 8 +-------------------------------------------------------------------------+ ... The last line number in the source file is 5, and there are 7 lines to display source lines, so if we'd scroll all the way down, the first line number in the source window would be 5, and the last one would be 11. To represent 11 we'd need 2 digits, so we expect to see ___04_ here instead of ___4_, even though all line numbers currently in the src window (3-9) can be represented with only 1 digit. Fix this in tui_source_window::set_contents, by updating the computation of max_line_nr: ... - int max_line_nr = std::max (lines_in_file, last_line_nr_in_window); + int max_line_nr = lines_in_file + nlines - 1; ... Tested on x86_64-linux. Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Approved-By: Tom Tromey <tom@tromey.com>
2023-05-10gdb/rust: fix crash for expression debug with stringsAndrew Burgess2-1/+25
While working on another patch I did this: (gdb) set debug expression 1 (gdb) set language rust (gdb) p "foo" Operation: OP_AGGREGATE Type: &str Fatal signal: Segmentation fault ... etc ... The problem is that the second field of the rust_aggregate_operation is created as a nullptr, this can be seen in rust-parse.c. in the function rust_parser::parse_string(). However, in expop.h, in the function dump_for_expression, we make the assumption that the expressions will never be nullptr. I did consider moving the nullptr handling into a new function rust_aggregate_operation::dump, however, as the expression debug dumping code is not exercised as much as it might be, I would rather that this code be hardened and able to handle a nullptr without crashing, so I propose that we add nullptr handling into the general dump_for_expression function. The behaviour is now: (gdb) set debug expression 1 (gdb) set language rust (gdb) p "foo" Operation: OP_AGGREGATE Type: &str nullptr Vector: String: data_ptr Operation: UNOP_ADDR Operation: OP_STRING String: foo String: length Operation: OP_LONG Type: usize Constant: 3 evaluation of this expression requires the target program to be active (gdb) There's a new test to check for this case. Reviewed-By: Tom Tromey <tom@tromey.com>
2023-05-10Re: stack overflow in debug_write_typeAlan Modra1-1/+2
Apparently u.kindirect->slot can point at a NULL. * debug.c (debug_write_type): Don't segfault on NULL indirect.
2023-05-10or1k relocation truncated to fit: R_OR1K_GOT16 even when using -mcmodel=largeLuca Bonissi2-3/+18
PR 30422 * elf32-or1k.c (or1k_elf_relocate_section): Prescan for R_OR1K_GOT_AHI16 relocs as they may occur after R_OR1K_GOT16 relocs.
2023-05-10Add linker option to include local symbols in the linker map.Nick Clifton10-2/+168
PR 16566 * ldlang.c (ld_is_local_symbol): New function. (print_input_section): Add code to display local symbols in the section. * ldlex.h (enum option_values): Add OPTION_PRINT_MAP_LOCALS and OPTION_PRINT_MAP_LOCALS. * lexsup.c (ld_options[]): Add entries for --print-map-locals and --no-print-map-locals. * NEWS: Mention the new feature. * ld.h (struct ld_config_type): Add print_map_locals field. * ld.texi: Document the new command line option. * testsuite/ld-scripts/sizeof.s: Add a local symbol. * testsuite/ld-scripts/map-locals.d: New test control file. * testsuite/ld-scripts/map-address.exp: Run the new test.
2023-05-10[gdb/tui] Fix tui compact-sourceTom de Vries4-8/+71
Consider a hello.c, with less than 10 lines: ... $ wc -l hello.c 8 hello.c ... and compiled with -g into an a.out. With compact-source off: ... $ gdb -q a.out \ -ex "set tui border-kind ascii" \ -ex "maint set tui-left-margin-verbose on" \ -ex "set tui compact-source off" \ -ex "tui enable" ... we get: ... +-./data/hello.c-----------------------+ |___000005_{ | |___000006_ printf ("hello\n"); | |___000007_ return 0; | |___000008_} | |___000009_ | |___000010_ | |___000011_ | ... but with compact-source on: ... +-./data/hello.c-----------------------+ |___5{ | |___6 printf ("hello\n"); | |___7 return 0; | |___8} | |___9 | |___1 | |___1 | ... There are a couple of problems with compact-source. First of all the documentation mentions: ... The default display uses more space for line numbers and starts the source text at the next tab stop; the compact display uses only as much space as is needed for the line numbers in the current file, and only a single space to separate the line numbers from the source. ... The bit about the default display and the next tab stop looks incorrect. The source doesn't start at a tab stop, instead it uses a single space to separate the line numbers from the source. Then the documentation mentions that there's single space in the compact display, but evidently that's missing. Then there's the fact that the line numbers "10" and "11" are both abbreviated to "1" in the compact case. The abbreviation is due to allocating space for <lines in source>, which is 8 for this example, and takes a single digit. The line numbers though continue past the end of the file, so fix this by allocating space for max (<lines in source>, <last line in window>), which in this example takes 2 digits. The missing space is due to some confusion about what the "1" here in tui_source_window::set_contents represent: ... double l = log10 ((double) offsets->size ()); m_digits = 1 + (int) l; ... It could be the trailing space that's mentioned in tui-source.h: ... /* How many digits to use when formatting the line number. This includes the trailing space. */ int m_digits; ... Then again, it could be part of the calculation for the number of digits needed for printing. With this minimal example: ... int main () { for (int i = 8; i <= 11; ++i) { double l = log10 ((double) i); printf ("%d %d\n", i, (int)l); } return 0; } ... we get: ... $ ./a.out 8 0 9 0 10 1 11 1 ... which shows that the number of digits needed for printing i is "1 + (int)log10 ((double) i)". Fix this by introducing named variables needed_digits and trailing_space, each adding 1. With the fixes, we get for compact-source on: ... +-./data/hello.c-----------------------+ |___05_{ | |___06_ printf ("hello\n"); | |___07_ return 0; | |___08_} | |___09_ | |___10_ | |___11_ | |... Also fix the documentation and help text to actually match effect of compact-source. Tested on x86_64-linux.
2023-05-10Automatic date update in version.inGDB Administrator1-1/+1
2023-05-09Support higher baud rates when they are definedDan Callaghan1-0/+66
On Linux at least, baud rate codes are defined up to B4000000. Allow the user to select them if they are present in the system headers. Change-Id: I393ff32e4a4b6127bdf97e3306ad5b6ebf7c934e
2023-05-09gdb: fix use-after-free in check_longjmp_breakpoint_for_call_dummySimon Marchi1-9/+16
Commit 7a8de0c33019 ("Remove ALL_BREAKPOINTS_SAFE") introduced a use-after-free in the breakpoints iterations (see below for full ASan report). This makes gdb.base/stale-infcall.exp fail when GDB is build with ASan. check_longjmp_breakpoint_for_call_dummy iterates on all breakpoints, possibly deleting the current breakpoint as well as related breakpoints. The problem arises when a breakpoint in the B->related_breakpoint chain is also B->next. In that case, deleting that related breakpoint frees the breakpoint that all_breakpoints_safe has saved. The old code worked around that by manually changing B_TMP, which was the next breakpoint saved by the "safe iterator": while (b->related_breakpoint != b) { if (b_tmp == b->related_breakpoint) b_tmp = b->related_breakpoint->next; delete_breakpoint (b->related_breakpoint); } (Note that this seemed to assume that b->related_breakpoint->next was the same as b->next->next, not sure this is guaranteed.) The new code kept the B_TMP variable, but it's not useful in that context. We can't go change the next breakpoint as saved by the safe iterator, like we did before. I suggest fixing that by saving the breakpoints to delete in a map and deleting them all at the end. Here's the full ASan report: (gdb) PASS: gdb.base/stale-infcall.exp: continue to breakpoint: break-run1 print infcall () ================================================================= ==47472==ERROR: AddressSanitizer: heap-use-after-free on address 0x611000034980 at pc 0x563f7012c7bc bp 0x7ffdf3804d70 sp 0x7ffdf3804d60 READ of size 8 at 0x611000034980 thread T0 #0 0x563f7012c7bb in next_iterator<breakpoint>::operator++() /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/next-iterator.h:66 #1 0x563f702ce8c0 in basic_safe_iterator<next_iterator<breakpoint> >::operator++() /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/safe-iterator.h:84 #2 0x563f7021522a in check_longjmp_breakpoint_for_call_dummy(thread_info*) /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:7611 #3 0x563f714567b1 in process_event_stop_test /home/smarchi/src/binutils-gdb/gdb/infrun.c:6881 #4 0x563f71454e07 in handle_signal_stop /home/smarchi/src/binutils-gdb/gdb/infrun.c:6769 #5 0x563f7144b680 in handle_inferior_event /home/smarchi/src/binutils-gdb/gdb/infrun.c:6023 #6 0x563f71436165 in fetch_inferior_event() /home/smarchi/src/binutils-gdb/gdb/infrun.c:4387 #7 0x563f7136ff51 in inferior_event_handler(inferior_event_type) /home/smarchi/src/binutils-gdb/gdb/inf-loop.c:42 #8 0x563f7168038d in handle_target_event /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:4219 #9 0x563f72fccb6d in handle_file_event /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:573 #10 0x563f72fcd503 in gdb_wait_for_event /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:694 #11 0x563f72fcaf2b in gdb_do_one_event(int) /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:217 #12 0x563f7262b9bb in wait_sync_command_done() /home/smarchi/src/binutils-gdb/gdb/top.c:426 #13 0x563f7137a7c3 in run_inferior_call /home/smarchi/src/binutils-gdb/gdb/infcall.c:650 #14 0x563f71381295 in call_function_by_hand_dummy(value*, type*, gdb::array_view<value*>, void (*)(void*, int), void*) /home/smarchi/src/binutils-gdb/gdb/infcall.c:1332 #15 0x563f7137c0e2 in call_function_by_hand(value*, type*, gdb::array_view<value*>) /home/smarchi/src/binutils-gdb/gdb/infcall.c:780 #16 0x563f70fe5960 in evaluate_subexp_do_call(expression*, noside, value*, gdb::array_view<value*>, char const*, type*) /home/smarchi/src/binutils-gdb/gdb/eval.c:649 #17 0x563f70fe6617 in expr::operation::evaluate_funcall(type*, expression*, noside, char const*, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/eval.c:677 #18 0x563f6fd19668 in expr::operation::evaluate_funcall(type*, expression*, noside, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/expression.h:136 #19 0x563f70fe6bba in expr::var_value_operation::evaluate_funcall(type*, expression*, noside, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/eval.c:689 #20 0x563f704b71dc in expr::funcall_operation::evaluate(type*, expression*, noside) /home/smarchi/src/binutils-gdb/gdb/expop.h:2219 #21 0x563f70fe0f02 in expression::evaluate(type*, noside) /home/smarchi/src/binutils-gdb/gdb/eval.c:110 #22 0x563f71b1373e in process_print_command_args /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1319 #23 0x563f71b1391b in print_command_1 /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1332 #24 0x563f71b147ec in print_command /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1465 #25 0x563f706029b8 in do_simple_func /home/smarchi/src/binutils-gdb/gdb/cli/cli-decode.c:95 #26 0x563f7061972a in cmd_func(cmd_list_element*, char const*, int) /home/smarchi/src/binutils-gdb/gdb/cli/cli-decode.c:2735 #27 0x563f7262d0ef in execute_command(char const*, int) /home/smarchi/src/binutils-gdb/gdb/top.c:572 #28 0x563f7100ed9c in command_handler(char const*) /home/smarchi/src/binutils-gdb/gdb/event-top.c:543 #29 0x563f7101014b in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) /home/smarchi/src/binutils-gdb/gdb/event-top.c:779 #30 0x563f72777942 in tui_command_line_handler /home/smarchi/src/binutils-gdb/gdb/tui/tui-interp.c:104 #31 0x563f7100d059 in gdb_rl_callback_handler /home/smarchi/src/binutils-gdb/gdb/event-top.c:250 #32 0x7f5a80418246 in rl_callback_read_char (/usr/lib/libreadline.so.8+0x3b246) (BuildId: 092e91fc4361b0ef94561e3ae03a75f69398acbb) #33 0x563f7100ca06 in gdb_rl_callback_read_char_wrapper_noexcept /home/smarchi/src/binutils-gdb/gdb/event-top.c:192 #34 0x563f7100cc5e in gdb_rl_callback_read_char_wrapper /home/smarchi/src/binutils-gdb/gdb/event-top.c:225 #35 0x563f728c70db in stdin_event_handler /home/smarchi/src/binutils-gdb/gdb/ui.c:155 #36 0x563f72fccb6d in handle_file_event /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:573 #37 0x563f72fcd503 in gdb_wait_for_event /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:694 #38 0x563f72fcb15c in gdb_do_one_event(int) /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:264 #39 0x563f7177ec1c in start_event_loop /home/smarchi/src/binutils-gdb/gdb/main.c:412 #40 0x563f7177f12e in captured_command_loop /home/smarchi/src/binutils-gdb/gdb/main.c:476 #41 0x563f717846e4 in captured_main /home/smarchi/src/binutils-gdb/gdb/main.c:1320 #42 0x563f71784821 in gdb_main(captured_main_args*) /home/smarchi/src/binutils-gdb/gdb/main.c:1339 #43 0x563f6fcedfbd in main /home/smarchi/src/binutils-gdb/gdb/gdb.c:32 #44 0x7f5a7e43984f (/usr/lib/libc.so.6+0x2384f) (BuildId: 2f005a79cd1a8e385972f5a102f16adba414d75e) #45 0x7f5a7e439909 in __libc_start_main (/usr/lib/libc.so.6+0x23909) (BuildId: 2f005a79cd1a8e385972f5a102f16adba414d75e) #46 0x563f6fcedd84 in _start (/home/smarchi/build/binutils-gdb/gdb/gdb+0xafb0d84) (BuildId: 50bd32e6e9d5e84543e9897b8faca34858ca3995) 0x611000034980 is located 0 bytes inside of 208-byte region [0x611000034980,0x611000034a50) freed by thread T0 here: #0 0x7f5a7fce312a in operator delete(void*, unsigned long) /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_new_delete.cpp:164 #1 0x563f702bd1fa in momentary_breakpoint::~momentary_breakpoint() /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:304 #2 0x563f702771c5 in delete_breakpoint(breakpoint*) /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:12404 #3 0x563f702150a7 in check_longjmp_breakpoint_for_call_dummy(thread_info*) /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:7673 #4 0x563f714567b1 in process_event_stop_test /home/smarchi/src/binutils-gdb/gdb/infrun.c:6881 #5 0x563f71454e07 in handle_signal_stop /home/smarchi/src/binutils-gdb/gdb/infrun.c:6769 #6 0x563f7144b680 in handle_inferior_event /home/smarchi/src/binutils-gdb/gdb/infrun.c:6023 #7 0x563f71436165 in fetch_inferior_event() /home/smarchi/src/binutils-gdb/gdb/infrun.c:4387 #8 0x563f7136ff51 in inferior_event_handler(inferior_event_type) /home/smarchi/src/binutils-gdb/gdb/inf-loop.c:42 #9 0x563f7168038d in handle_target_event /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:4219 #10 0x563f72fccb6d in handle_file_event /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:573 #11 0x563f72fcd503 in gdb_wait_for_event /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:694 #12 0x563f72fcaf2b in gdb_do_one_event(int) /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:217 #13 0x563f7262b9bb in wait_sync_command_done() /home/smarchi/src/binutils-gdb/gdb/top.c:426 #14 0x563f7137a7c3 in run_inferior_call /home/smarchi/src/binutils-gdb/gdb/infcall.c:650 #15 0x563f71381295 in call_function_by_hand_dummy(value*, type*, gdb::array_view<value*>, void (*)(void*, int), void*) /home/smarchi/src/binutils-gdb/gdb/infcall.c:1332 #16 0x563f7137c0e2 in call_function_by_hand(value*, type*, gdb::array_view<value*>) /home/smarchi/src/binutils-gdb/gdb/infcall.c:780 #17 0x563f70fe5960 in evaluate_subexp_do_call(expression*, noside, value*, gdb::array_view<value*>, char const*, type*) /home/smarchi/src/binutils-gdb/gdb/eval.c:649 #18 0x563f70fe6617 in expr::operation::evaluate_funcall(type*, expression*, noside, char const*, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/eval.c:677 #19 0x563f6fd19668 in expr::operation::evaluate_funcall(type*, expression*, noside, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/expression.h:136 #20 0x563f70fe6bba in expr::var_value_operation::evaluate_funcall(type*, expression*, noside, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/eval.c:689 #21 0x563f704b71dc in expr::funcall_operation::evaluate(type*, expression*, noside) /home/smarchi/src/binutils-gdb/gdb/expop.h:2219 #22 0x563f70fe0f02 in expression::evaluate(type*, noside) /home/smarchi/src/binutils-gdb/gdb/eval.c:110 #23 0x563f71b1373e in process_print_command_args /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1319 #24 0x563f71b1391b in print_command_1 /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1332 #25 0x563f71b147ec in print_command /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1465 #26 0x563f706029b8 in do_simple_func /home/smarchi/src/binutils-gdb/gdb/cli/cli-decode.c:95 #27 0x563f7061972a in cmd_func(cmd_list_element*, char const*, int) /home/smarchi/src/binutils-gdb/gdb/cli/cli-decode.c:2735 #28 0x563f7262d0ef in execute_command(char const*, int) /home/smarchi/src/binutils-gdb/gdb/top.c:572 #29 0x563f7100ed9c in command_handler(char const*) /home/smarchi/src/binutils-gdb/gdb/event-top.c:543 previously allocated by thread T0 here: #0 0x7f5a7fce2012 in operator new(unsigned long) /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_new_delete.cpp:95 #1 0x563f7029a9a3 in new_momentary_breakpoint<program_space*&, frame_id&, int&> /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:8129 #2 0x563f702212f6 in momentary_breakpoint_from_master /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:8169 #3 0x563f70212db1 in set_longjmp_breakpoint_for_call_dummy() /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:7582 #4 0x563f713804db in call_function_by_hand_dummy(value*, type*, gdb::array_view<value*>, void (*)(void*, int), void*) /home/smarchi/src/binutils-gdb/gdb/infcall.c:1260 #5 0x563f7137c0e2 in call_function_by_hand(value*, type*, gdb::array_view<value*>) /home/smarchi/src/binutils-gdb/gdb/infcall.c:780 #6 0x563f70fe5960 in evaluate_subexp_do_call(expression*, noside, value*, gdb::array_view<value*>, char const*, type*) /home/smarchi/src/binutils-gdb/gdb/eval.c:649 #7 0x563f70fe6617 in expr::operation::evaluate_funcall(type*, expression*, noside, char const*, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/eval.c:677 #8 0x563f6fd19668 in expr::operation::evaluate_funcall(type*, expression*, noside, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/expression.h:136 #9 0x563f70fe6bba in expr::var_value_operation::evaluate_funcall(type*, expression*, noside, std::__debug::vector<std::unique_ptr<expr::operation, std::default_delete<expr::operation> >, std::allocator<std::unique_ptr<expr::operation, std::default_delete<expr::operation> > > > const&) /home/smarchi/src/binutils-gdb/gdb/eval.c:689 #10 0x563f704b71dc in expr::funcall_operation::evaluate(type*, expression*, noside) /home/smarchi/src/binutils-gdb/gdb/expop.h:2219 #11 0x563f70fe0f02 in expression::evaluate(type*, noside) /home/smarchi/src/binutils-gdb/gdb/eval.c:110 #12 0x563f71b1373e in process_print_command_args /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1319 #13 0x563f71b1391b in print_command_1 /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1332 #14 0x563f71b147ec in print_command /home/smarchi/src/binutils-gdb/gdb/printcmd.c:1465 #15 0x563f706029b8 in do_simple_func /home/smarchi/src/binutils-gdb/gdb/cli/cli-decode.c:95 #16 0x563f7061972a in cmd_func(cmd_list_element*, char const*, int) /home/smarchi/src/binutils-gdb/gdb/cli/cli-decode.c:2735 #17 0x563f7262d0ef in execute_command(char const*, int) /home/smarchi/src/binutils-gdb/gdb/top.c:572 #18 0x563f7100ed9c in command_handler(char const*) /home/smarchi/src/binutils-gdb/gdb/event-top.c:543 #19 0x563f7101014b in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) /home/smarchi/src/binutils-gdb/gdb/event-top.c:779 #20 0x563f72777942 in tui_command_line_handler /home/smarchi/src/binutils-gdb/gdb/tui/tui-interp.c:104 #21 0x563f7100d059 in gdb_rl_callback_handler /home/smarchi/src/binutils-gdb/gdb/event-top.c:250 #22 0x7f5a80418246 in rl_callback_read_char (/usr/lib/libreadline.so.8+0x3b246) (BuildId: 092e91fc4361b0ef94561e3ae03a75f69398acbb) Change-Id: Id00c17ab677f847fbf4efdf0f4038373668d3d88 Approved-By: Tom Tromey <tom@tromey.com>
2023-05-09Correct a spelling mistake in the binutils README file.Enze Li2-1/+5
2023-05-09stack overflow in debug_write_typeAlan Modra1-1/+6
Another fuzzer attack. This one was a "set" with elements using an indirect type pointing back at the set. The existing recursion check only prevented simple recursion. * debug.c (struct debug_type_s): Add mark. (debug_write_type): Set mark and check before recursing into indirect types.
2023-05-09alpha-vms reloc sanity checkAlan Modra1-2/+22
Stops fuzzed files triggering reads past the end of the reloc buffer. * vms-alpha.c (alpha_vms_slurp_relocs): Sanity check reloc records.
2023-05-09regen ld/Makefile.inAlan Modra1-33/+45
2023-05-09Automatic date update in version.inGDB Administrator1-1/+1
2023-05-08gdbserver: Clear upper ZMM registers in the right location.John Baldwin1-1/+1
This was previously clearing the upper 32 bytes of ZMM0-15 rather than ZMM16-31. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-05-08x86-fbsd-nat: Add missing public label.John Baldwin1-0/+1
These two methods are both overrides of public methods in base classes.
2023-05-08gdb: Avoid warning for the jump command inside an inline function.Felix Willgerodt3-1/+76
When stopped inside an inline function, trying to jump to a different line of the same function currently results in a warning about jumping to another function. Fix this by taking inline functions into account. Before: Breakpoint 1, function_inline (x=510) at jump-inline.cpp:22 22 a = a + x; /* inline-funct */ (gdb) j 21 Line 21 is not in `function_inline(int)'. Jump anyway? (y or n) After: Breakpoint 2, function_inline (x=510) at jump-inline.cpp:22 22 a = a + x; /* inline-funct */ (gdb) j 21 Continuing at 0x400679. Breakpoint 1, function_inline (x=510) at jump-inline.cpp:21 21 a += 1020 + a; /* increment-funct */ This was regression-tested on X86-64 Linux. Co-Authored-by: Cristian Sandu <cristian.sandu@intel.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-05-08pe.em and pep.em make_import_fixupAlan Modra2-40/+76
This is a little cleanup that I made when looking at pr30343 that makes it more obvious that make_import_fixup in both files are identical (and in fact the new pep.em read_addend could be used in both files). * emultempl/pep.em (read_addend): Extract from.. (make_import_fixup): ..here. * emultempl/pe.em (read_addend): Similarly. (make_import_fixup): Similarly. Add debug code from pep.em.
2023-05-08PR30343, LTO ignores linker reference to _pei386_runtime_relocatorAlan Modra3-0/+67
Make a reference to _pei386_runtime_relocator before LTO recompilation. This is done regardless of whether such a reference will be used, because it can't be known whether it is needed before LTO. I also found it necessary to enable long section names for the bfd created in make_runtime_pseudo_reloc, because otherwise when writing it out to the bfd-in-memory we get the section written as .rdata_r which when read back in leads to a linker warning ".rdata_r: section below image base" and likely runtime misbehaviour. PR 30343 * emultempl/pe.em (make_runtime_ref): New function. (gld${EMULATION_NAME}_before_plugin_all_symbols_read): New function. (LDEMUL_BEFORE_PLUGIN_ALL_SYMBOLS_READ): Define. * emultempl/pep.em: Similarly to pe.em. * pe-dll.c (make_runtime_pseudo_reloc): Set long section names.
2023-05-08Automatic date update in version.inGDB Administrator1-1/+1
2023-05-07Remove parameter from select_source_symtabTom Tromey2-20/+10
I noticed that select_source_symtab is only ever called with nullptr as an argument, so this patch removes the parameter and associated logic. Reviewed-By: Bruno Larsen <blarsen@redhat.com>
2023-05-07Remove ALL_BREAKPOINTS_SAFETom Tromey1-71/+63
There's just a single remaining use of the ALL_BREAKPOINTS_SAFE macro; this patch replaces it with a for-each and an explicit temporary variable.
2023-05-07Remove ALL_DICT_SYMBOLSTom Tromey5-30/+57
This replaces ALL_DICT_SYMBOLS with an iterator so that for-each can be used.
2023-05-07Remove ALL_OBJFILE_OSECTIONSTom Tromey20-276/+294
This replaces ALL_OBJFILE_OSECTIONS with an iterator so that for-each can be used.
2023-05-07Rename objfile::sectionsTom Tromey11-29/+30
I think objfile::sections makes sense as the name of the method to iterate over an objfile's sections, so this patch renames the existing field to objfile::sections_start in preparation for that.
2023-05-07Automatic date update in version.inGDB Administrator1-1/+1
2023-05-06Allow pretty-print of static membersTom Tromey3-16/+47
Python pretty-printers haven't applied to static members for quite some time. I tracked this down to the call to cp_print_value_fields in cp_print_static_field -- it doesn't let pretty-printers have a chance to print the value. This patch fixes the problem. The way that static members are handled is very weird to me. I tend to think this should be done more globally, like in value_print. However, I haven't made any big change. Reviewed-by: Keith Seitz <keiths@redhat.com> Tested-by: Keith Seitz <keiths@redhat.com> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30057
2023-05-06gas: documents .gnu_attribute Tag_GNU_MIPS_ABI_MSAYunQiang Su1-0/+11
It is added since 2016 by Add support for .MIPS.abiflags and .gnu.attributes sections b52717c0e104eb603e8189c3c0d3658ef5d903f5 But never documented.
2023-05-06Automatic date update in version.inGDB Administrator1-1/+1
2023-05-05Filter out types from DAP scopes requestTom Tromey2-7/+7
The DAP scopes request examines the symbols in a block tree, but neglects to omit types. This patch fixes the problem.
2023-05-05Use discrete_position in ada-valprint.cTom Tromey1-30/+9
I found a couple of spots in ada-valprint.c that use an explicit loop, but where discrete_position could be used instead. Reviewed-by: Keith Seitz <keiths@redhat.com>
2023-05-05gdb/python: add mechanism to manage Python initialization functionsAndrew Burgess35-158/+254
Currently, when we add a new python sub-system to GDB, e.g. py-inferior.c, we end up having to create a new function like gdbpy_initialize_inferior, which then has to be called from the function do_start_initialization in python.c. In some cases (py-micmd.c and py-tui.c), we have two functions gdbpy_initialize_*, and gdbpy_finalize_*, with the second being called from finalize_python which is also in python.c. This commit proposes a mechanism to manage these initialization and finalization calls, this means that adding a new Python subsystem will no longer require changes to python.c or python-internal.h, instead, the initialization and finalization functions will be registered directly from the sub-system file, e.g. py-inferior.c, or py-micmd.c. The initialization and finalization functions are managed through a new class gdbpy_initialize_file in python-internal.h. This class contains a single global vector of all the initialization and finalization functions. In each Python sub-system we create a new gdbpy_initialize_file object, the object constructor takes care of registering the two callback functions. Now from python.c we can call static functions on the gdbpy_initialize_file class which take care of walking the callback list and invoking each callback in turn. To slightly simplify the Python sub-system files I added a new macro GDBPY_INITIALIZE_FILE, which hides the need to create an object. We can now just do this: GDBPY_INITIALIZE_FILE (gdbpy_initialize_registers); One possible problem with this change is that there is now no guaranteed ordering of how the various sub-systems are initialized (or finalized). To try and avoid dependencies creeping in I have added a use of the environment variable GDB_REVERSE_INIT_FUNCTIONS, this is the same environment variable used in the generated init.c file. Just like with init.c, when this environment variable is set we reverse the list of Python initialization (and finalization) functions. As there is already a test that starts GDB with the environment variable set then this should offer some level of protection against dependencies creeping in - though for full protection I guess we'd need to run all gdb.python/*.exp tests with the variable set. I have tested this patch with the environment variable set, and saw no regressions, so I think we are fine right now. One other change of note was for gdbpy_initialize_gdb_readline, this function previously returned void. In order to make this function have the correct signature I've updated its return type to int, and we now return 0 to indicate success. All of the other initialize (and finalize) functions have been made static within their respective sub-system files. There should be no user visible changes after this commit.
2023-05-05gdb/testsuite: more newline pattern cleanupAndrew Burgess5-9/+9
After this commit: commit e2f620135d92f7cd670af4e524fffec7ac307666 Date: Thu Mar 30 13:26:25 2023 +0100 gdb/testsuite: change newline patterns used in gdb_test It was pointed out in PR gdb/30403 that the same patterns can be found in other lib/gdb.exp procs and that it would probably be a good idea if these procs remained in sync with gdb_test. Actually, the bug specifically calls out gdb_test_multiple when using with '-wrap', but I found a couple of other locations in gdb_continue_to_breakpoint, gdb_test_multiline, get_valueof, and get_local_valueof. In all these locations one or both of the following issues are addressed: 1. A leading pattern of '[\r\n]*' is pointless. If there is a newline it will be matched, but if there is not then the testsuite doesn't care. Also, as expect is happy to skip non-matched output at the start of a pattern, if there is a newline expect is happy to skip over it before matching the rest. As such, this leading pattern is removed. 2. Using '\[\r\n\]*$gdb_prompt' means that we will swallow unexpected blank lines at the end of a command's output, but also, if the pattern from the test script ends with a '\r', '\n', or '.' then these will partially match the trailing newline, with the remainder of the newline matched by the pattern from gdb.exp. This split matching doesn't add any value, it's just something that has appeared as a consequence of how gdb.exp was originally written. In this case the '\[\r\n\]*' is replaced with '\r\n'. I've rerun the testsuite and fixed the regressions that I saw, these were places where GDB emits a blank line at the end of the command output, which we now need to explicitly match in the test script, this was for: gdb.dwarf2/dw2-out-of-range-end-of-seq.exp gdb.guile/guile.exp gdb.python/python.exp Or a location where the test script was matching part of the newline sequence, while gdb.exp was previously matching the remainder of the newline sequence. Now we rely on gdb.exp to match the complete newline sequence, this was for: gdb.base/commands.exp Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30403
2023-05-05[gdb/testsuite] Generate long string in gdb.base/page.expTom de Vries1-1/+1
I noticed in gdb.base/page.exp: ... set fours [string repeat 4 40] ... but then shortly afterwards: ... [list 1\r\n 2\r\n 3\r\n 444444444444444444444444444444] ... Summarize the long string in the same way using string repeat: ... [list 1\r\n 2\r\n 3\r\n [string repeat 4 30]] ... Tested on x86_64-linux.
2023-05-05gdb/testsuite: tighten patterns in build-id-no-debug-warning.expAndrew Burgess1-2/+4
Tighten the expected output pattern in the test script: gdb.debuginfod/build-id-no-debug-warning.exp While working on some other patch I broke GDB such that this warning: warning: "FILENAME": separate debug info file has no debug info (which is generated in build-id.c) didn't actually include the FILENAME any more -- yet this test script continued to pass. It turns out that this script doesn't actually check for FILENAME. This commit extends the test pattern to check for the full warning string, including FILENAME, and also removes some uses of '.*' to make the test stricter.
2023-05-05Simplify decode_locdescTom Tromey1-137/+66
While looking into another bug, I noticed that the DWARF cooked indexer picks up an address for this symbol: <1><82>: Abbrev Number: 2 (DW_TAG_variable) <83> DW_AT_specification: <0x9f> <87> DW_AT_location : 10 byte block: e 0 0 0 0 0 0 0 0 e0 (DW_OP_const8u: 0 0; DW_OP_GNU_push_tls_address or DW_OP_HP_unknown) <92> DW_AT_linkage_name: (indirect string, offset: 0x156): _ZN9container8tlsvar_0E This happens because decode_locdesc allows the use of DW_OP_GNU_push_tls_address. This didn't make sense to me. I looked into it a bit more, and I think decode_locdesc is used in three ways: 1. Find a constant address of a symbol that happens to be encoded as a location expression. 2. Find the offset of a function in a virtual table. (This one should probably be replaced by code to just evaluate the expression in gnu-v3-abi.c -- but there's no point yet because no compiler actually seems to emit correct DWARF here, see the bug linked in the patch.) 3. Find the offset of a field, if the offset is a constant. None of these require TLS. This patch simplifies decode_locdesc by removing any opcodes that don't fit into the above. It also changes the API a little, to make it less difficult to use. Regression tested on x86-64 Fedora 36.
2023-05-05Simplify auto_load_expand_dir_vars and remove substitute_path_componentTom Tromey5-121/+21
This simplifies auto_load_expand_dir_vars to first split the string, then do any needed substitutions. This was suggested by Simon, and is much simpler than the current approach. Then this patch also removes substitute_path_component, as it is no longer called. This is nice because it helps with the long term goal of removing utils.h. Regression tested on x86-64 Fedora 36.
2023-05-05[gdb/testsuite] Add gdb.base/wrap-line.expTom de Vries1-0/+169
Add a test-case that tests prompt edit wrapping in CLI, both for TERM=xterm and TERM=ansi, both with auto-detected and hard-coded width. In the TERM=ansi case with auto-detected width we run into PR cli/30346, so add a KFAIL for that failure mode. Tested on x86_64-linux.
2023-05-05[gdb/testsuite] Add gdb.tui/wrap-line.expTom de Vries2-14/+188
Add a test-case that tests prompt edit wrapping behaviour in the tuiterm, both for CLI and TUI, both with auto-detected and hard-coded width. In the CLI case with auto-detected width we run into PR cli/30411, so add a KFAIL for that failure mode. Tested on x86_64-linux.
2023-05-05Debug info is lost for functions only called from functions marked with ↵Nick Clifton2-3/+21
cmse_nonsecure_entr PR 30354 * elf32-arm.c (elf32_arm_gc_mark_extra_sections): If any debug sections are marked then rerun the extra marking in order to pick up any dependencies.
2023-05-05Automatic date update in version.inGDB Administrator1-1/+1
2023-05-04Revert "gdb/testsuite: add KFAILs to gdb.reverse/step-reverse.exp"Bruno Larsen1-15/+0
This reverts commit 476410b3bca1389ee69e9c8fa18aaee16793a56d. One of Simon's recent commits (2a740b3ba4c9f39c86dd75e0914ee00942cab471) changed the way recording a remote target works and fixed the underlying issue of the bug, so the KFails can be removed from the test. Approved-By: Tom Tromey <tom@tromey.com>
2023-05-04Don't treat references to compound values as "simple".Gareth Rees10-25/+175
SUMMARY The '--simple-values' argument to '-stack-list-arguments' and similar GDB/MI commands does not take reference types into account, so that references to arbitrarily large structures are considered "simple" and printed. This means that the '--simple-values' argument cannot be used by IDEs when tracing the stack due to the time taken to print large structures passed by reference. DETAILS Various GDB/MI commands ('-stack-list-arguments', '-stack-list-locals', '-stack-list-variables' and so on) take a PRINT-VALUES argument which may be '--no-values' (0), '--all-values' (1) or '--simple-values' (2). In the '--simple-values' case, the command is supposed to print the name, type, and value of variables with simple types, and print only the name and type of variables with compound types. The '--simple-values' argument ought to be suitable for IDEs that need to update their user interface with the program's call stack every time the program stops. However, it does not take C++ reference types into account, and this makes the argument unsuitable for this purpose. For example, consider the following C++ program: struct s { int v[10]; }; int sum(const struct s &s) { int total = 0; for (int i = 0; i < 10; ++i) total += s.v[i]; return total; } int main(void) { struct s s = { { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 } }; return sum(s); } If we start GDB in MI mode and continue to 'sum', the behaviour of '-stack-list-arguments' is as follows: (gdb) -stack-list-arguments --simple-values ^done,stack-args=[frame={level="0",args=[{name="s",type="const s &",value="@0x7fffffffe310: {v = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10}}"}]},frame={level="1",args=[]}] Note that the value of the argument 's' was printed, even though 's' is a reference to a structure, which is not a simple value. See https://github.com/microsoft/MIEngine/pull/673 for a case where this behaviour caused Microsoft to avoid the use of '--simple-values' in their MIEngine debug adapter, because it caused Visual Studio Code to take too long to refresh the call stack in the user interface. SOLUTIONS There are two ways we could fix this problem, depending on whether we consider the current behaviour to be a bug. 1. If the current behaviour is a bug, then we can update the behaviour of '--simple-values' so that it takes reference types into account: that is, a value is simple if it is neither an array, struct, or union, nor a reference to an array, struct or union. In this case we must add a feature to the '-list-features' command so that IDEs can detect that it is safe to use the '--simple-values' argument when refreshing the call stack. 2. If the current behaviour is not a bug, then we can add a new option for the PRINT-VALUES argument, for example, '--scalar-values' (3), that would be suitable for use by IDEs. In this case we must add a feature to the '-list-features' command so that IDEs can detect that the '--scalar-values' argument is available for use when refreshing the call stack. PATCH This patch implements solution (1) as I think the current behaviour of not printing structures, but printing references to structures, is contrary to reasonable expectation. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29554
2023-05-04Stop the linker from loosing the entry point for COFF/PE code when compiling ↵Nick Clifton3-0/+13
with LTO enabled. PR 30300 * emultempl/pep.em (set_entry_point): Add an undefined reference to the entry point if it has been constructed heuristically. * emultempl/pe.em (set_entry_point): Likewise.
2023-05-04ld: pru: Place exception-handling sections correctlyDimitar Dimitrov2-8/+36
* scripttempl/pru.sc (OUTPUT_SECTION_ALIGN): New helper variable to place at end of DMEM output sections. (.data): Use the helper variable. (.eh_frame): New output section. (.gnu_extab): Ditto. (.gcc_except_table): Ditto. (.resource_table): Use the helper variable.
2023-05-04RISC-V: tighten post-relocation-operator separator expectationJan Beulich3-1/+8
As per the spec merely a blank isn't okay as a separator, the operand to the relocation function ought to be parenthesized. Enforcing this then also eliminates an inconsistency in that lui t0, %hi sym lui t0, %hi 0x1000 were accepted, but lui t0, %hi +sym lui t0, %hi -0x1000 were not.
2023-05-04gas: fix building tc-bpf.c on s390xIlya Leoshkevich1-2/+4
char is unsigned on s390x, so there are a lot of warnings like: gas/config/tc-bpf.c: In function 'get_token': gas/config/tc-bpf.c:900:14: error: comparison is always false due to limited range of data type [-Werror=type-limits] 900 | if (ch == EOF || len > MAX_TOKEN_SZ) | ^~ Change its type to int, like in the other similar code. There is also: gas/config/tc-bpf.c:735:30: error: 'bpf_endianness' may be used uninitialized in this function [-Werror=maybe-uninitialized] 735 | dst, be ? size[endianness - BPF_BE16] : size[endianness - BPF_LE16]); | ~~~~~~~~~~~^~~~~~~~~~ -Wmaybe-uninitialized doesn't seem to understand the FSM; just initialize bpf_endianness to silence it. Add an assertion to build_bpf_endianness() in order to catch potential bugs.
2023-05-04MIPS: revert "default r6 if vendor is img"YunQiang Su3-19/+1
In commit: 9171de358f230b64646bbb525a74e5f8e3dbe0dc, The default output is set to r6 if the vendor is img, It is ugly and should not be in upstream. Let's revert it.
generated by cgit v1.1 at 2024-11-16 02:16:05 +0000