aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2019-12-12Fix unused function errorLuis Machado2-10/+8
Attempting to build GDB in Ubuntu 16.04.6 LTS on x86_64, I ran into warnings that caused the build to fail: binutils-gdb/gdb/gdbsupport/safe-strerror.c:44:1: error: ‘char* select_strerror_r(char*, char*)’ defined but not used [-Werror=unused-function] select_strerror_r (char *res, char *) The diagnostic macro DIAGNOSTIC_IGNORE_UNUSED_FUNCTION seems to expand correctly to its respective pragma, but this doesn't seem to have an effect on the warning. I tried to use the pragma explicitly and got the same result. ATTRIBUTE_UNUSED works fine in this case if you put it in both functions, which should fix warnings for both gdb and gdbserver builds. The compiler version is gcc (Ubuntu 5.4.0-6ubuntu1~16.04.11) 5.4.0 20160609. This is likely the result of PR64079 in GCC, which was fixed by commit 9e96f1e1b9731c4e1ef4fbbbf0997319973f0537. To prevent other developers from attempting to use this macro, only to get confused by it not working as expected, it seems better to not define this particular macro. gdb/ChangeLog: 2019-12-12 Luis Machado <luis.machado@linaro.org> * gdbsupport/safe-strerror.c: Don't include diagnostics.h. (select_strerror_r): Use ATTRIBUTE_UNUSED instead of the diagnostics macros. include/ChangeLog: 2019-12-12 Luis Machado <luis.machado@linaro.org> * diagnostics.h (DIAGNOSTIC_IGNORE_UNUSED_FUNCTION). Remove definitions. Change-Id: Iad6123d61d76d111e3ef8d24aa8c60112304c749
2019-12-11Fix TUI test suite regexpsTom Tromey4-4/+10
Testing on another TUI series showed that some of the regexps in the TUI test suite have been incorrect for a while. In particular, "|" was meant literally in these tests, but was interpreted as pattern alternation due to lack of quoting. This patch fixes the bad tests. I am checking this in. gdb/testsuite/ChangeLog 2019-12-11 Tom Tromey <tom@tromey.com> * gdb.tui/resize.exp: Fix regexp. * gdb.tui/regs.exp: Fix regexps. * gdb.tui/main.exp: Fix regexp. Change-Id: Ib6661361171ac120bb92f4a8aec7efa4bcaa36b9
2019-12-11Change "winheight" resizing to use new layout codeTom Tromey4-279/+22
The "winheight" command resizes a specified window, resizing the other windows in the layout to adapt. In the current code, this is done by examining each possible layout separately. The new layout code has a more general approach to handling this, and this patch simply removes the old code in favor of a call into the new layout engine. gdb/ChangeLog 2019-12-11 Tom Tromey <tom@tromey.com> * tui/tui-win.c (tui_set_win_height_command): Call tui_adjust_window_height. (tui_adjust_win_heights, new_height_ok): Remove. * tui/tui-layout.h (tui_adjust_window_height): Declare. * tui/tui-layout.c (tui_adjust_window_height): New function. Change-Id: I6bb681375a46adc8d29fd06f581deed4e078e78a
2019-12-11Re-apply the current layout when resizingTom Tromey5-111/+19
The TUI has separate code for each possible layout to handle the case where the terminal window is resized. With the new layout code, this can all be replaced with a call to tui_apply_current_layout, which simply re-applies the current layout. This results in some small differences in behavior when resizing, so some tests are updated. gdb/ChangeLog 2019-12-11 Tom Tromey <tom@tromey.com> * tui/tui-win.c (tui_resize_all): Remove code, call tui_apply_current_layout. gdb/testsuite/ChangeLog 2019-12-11 Tom Tromey <tom@tromey.com> * gdb.tui/resize.exp: Update. * gdb.tui/empty.exp (layouts): Update. Change-Id: I3dc6c02a753d495d9ab5e8213d550a147198ce6f
2019-12-11First use of tui_layoutTom Tromey8-182/+84
This patch introduces the first use of tui_layout, by changing show_layout to clone and use the appropriate tui_layout. This resulted in one minor layout change, and also in the unintended -- but good -- side effect that the title of each boxed window is now visible. gdb/ChangeLog 2019-12-11 Tom Tromey <tom@tromey.com> * tui/tui-layout.h (tui_apply_current_layout): Declare. * tui/tui-layout.c (standard_layouts, applied_layout): New globals. (tui_apply_current_layout): New function. (show_layout): Set applied_layout. Call tui_apply_current_layout. (show_source_command, show_disasm_command) (show_source_disasm_command, show_data) (show_source_or_disasm_and_command): Remove. (initialize_layouts): New function. (_initialize_tui_layout): Call initialize_layouts. gdb/testsuite/ChangeLog 2019-12-11 Tom Tromey <tom@tromey.com> * gdb.tui/regs.exp: Update. * gdb.tui/empty.exp (layouts): Update. * gdb.tui/basic.exp: Update. * lib/tuiterm.exp (_check_box): Don't check bottom border. Change-Id: If1ee06ee58f4803e8c213f4ab0f5bb59f4650ec2
2019-12-11Introduce new layout codeTom Tromey3-0/+522
This introduces a new approach to window layout for the TUI. The idea behind this code is that a layout should be specified in a declarative way, and then be applied by generic code that does not need to know the specifics of every possible layout. This patch itself does not change any behavior, because the new layout engine isn't yet connected to anything. That is, this merely introduces the implementation. This generic approach makes the code more maintainable. It also enables some future changes: * New window types are simpler to add; * User-specified layouts are possible; and * Horizontal layouts are more attainable gdb/ChangeLog 2019-12-11 Tom Tromey <tom@tromey.com> * tui/tui-layout.h (class tui_layout_base) (class tui_layout_window, class tui_layout_split): New. * tui/tui-layout.c (tui_get_window_by_name) (tui_layout_window::clone, tui_layout_window::apply) (tui_layout_window::get_sizes, tui_layout_window::add_split) (tui_layout_split::add_window, tui_layout_split::clone) (tui_layout_split::get_sizes) (tui_layout_split::set_weights_from_heights) (tui_layout_split::adjust_size, tui_layout_split::apply): New functions. (tui_layout_split::add_split, tui_layout_split::add_split) (tui_layout_split::set_weights_from_heights) (tui_layout_split::set_weights_from_heights): New functions. Change-Id: I3a4cae666327b617d862aaa356f8179f945c6a4e
2019-12-11Remove struct tui_pointTom Tromey6-30/+35
struct tui_point does not help very much. It is only used for storage, and never passed between functions. I think it makes the code more verbose without any corresponding benefit, so this patch removes it. gdb/ChangeLog 2019-12-11 Tom Tromey <tom@tromey.com> * tui/tui-wingeneral.c (tui_gen_win_info::make_window): Update. * tui/tui-win.c (tui_adjust_win_heights, tui_resize_all): Update. * tui/tui-layout.c (tui_gen_win_info::resize): Update. * tui/tui-data.h (struct tui_point): Remove. (struct tui_gen_win_info) <origin>: Remove. <x, y>: New fields. * tui/tui-command.c (tui_cmd_window::resize): Update. Change-Id: I3f77920585b9ea9e2b4b189f3f3ae32d4da0c252
2019-12-11Introduce the tui_gen_win_info::min_height methodTom Tromey4-0/+28
This introduces a new method, tui_gen_win_info::min_height, to fetch the minimum height of a window. This is used in the subsequent unified layout patch. gdb/ChangeLog 2019-12-11 Tom Tromey <tom@tromey.com> * tui/tui-stack.h (struct tui_locator_window) <min_height>: Implement. * tui/tui-regs.h (struct tui_data_item_window) <min_height>: Implement. * tui/tui-data.h (struct tui_gen_win_info) <min_height>: New method. (struct tui_win_info) <min_height>: Implement. Change-Id: Id33baffdf041fde072e15c1ff89b75f8b8118adb
2019-12-11Move can_box to tui_gen_win_infoTom Tromey2-1/+12
This moves the can_box method to tui_gen_win_info, so that it will be available on the tui_locator_window class. This will be used in a subsequent patch. gdb/ChangeLog 2019-12-11 Tom Tromey <tom@tromey.com> * tui/tui-data.h (struct tui_gen_win_info) <can_box>: New method. (struct tui_win_info) <can_box>: Update. Change-Id: Idfa58af41341607932d3c39415f6a35ee9b5d3dc
2019-12-11Move max_height method to tui_gen_win_infoTom Tromey4-2/+24
This moves the max_height method to tui_gen_win_info and implements it in the subclasses. This is used by a subsequent patch, which will normalize window layout across all window types. gdb/ChangeLog 2019-12-11 Tom Tromey <tom@tromey.com> * tui/tui-stack.h (struct tui_locator_window) <max_height>: New method. * tui/tui-regs.h (struct tui_data_item_window) <max_height>: New method. * tui/tui-data.h (struct tui_gen_win_info) <max_height>: New method. (struct tui_win_info) <max_height>: Now override. Change-Id: I4ba3e8899bc4668328d3d78e3c1674c61882450d
2019-12-11Update NEWS post GDB 9 branch creation.Joel Brobecker2-1/+9
gdb/ChangeLog: * NEWS: Create a new section for the next release branch. Rename the section of the current branch, now that it has been cut.
2019-12-11Bump version to 10.0.50.DATE-git.Joel Brobecker2-1/+6
Now that the GDB 9 branch has been created, we can bump the version number. gdb/ChangeLog: GDB 9 branch created (27f7b2f64062ac9e52afc60509263c2702a9ebd0): * version.in: Bump version to 10.0.50.DATE-git.
2019-12-11Fix typo, get_Frame_id -> get_frame_idgdb-9-branchpointSimon Marchi2-1/+5
gdb/doc/ChangeLog: * gdb.texinfo (Writing JIT Debug Info Readers): Fix typo.
2019-12-11Fix build on macOSTom Tromey2-4/+38
PR build/25268 points out that the build fails on macOS, because on macOS the "pthread_setname_np" function takes a single argument. This patch fixes the problem, by introducing a new adapter function that handles both styles of pthread_setname_np. This change also meant moving the pthread_setname_np call to the thread function, because macOS only permits setting the name of the current thread. This means that there can be a brief window when gdb will see the wrong name; but I think this is a minor concern. Tested by rebuilding on x86-64 Fedora 30, and on macOS High Sierra. On Linux I also debugged gdb to ensure that the thread names are still set correctly. gdb/ChangeLog 2019-12-11 Tom Tromey <tromey@adacore.com> PR build/25268: * gdbsupport/thread-pool.c (set_thread_name): New function. (thread_pool::set_thread_count): Don't call pthread_setname_np. (thread_pool::thread_function): Call set_thread_name. Change-Id: Id7bf28d99ca27a893a9fc87ebb90b15a9c2a9cb4
2019-12-11Fix the build after bfd_get_signed_8 changeTom Tromey2-1/+6
A recent commit changed bfd_get_signed_8 to extend the result to a bfd_signed_vma. This caused a compiler error in one spot in my --enable-targets=all gdb build, where the result of bfd_get_signed_8 was passed to printf. This patch fixes the build. Tested by rebuilding. gdb/ChangeLog 2019-12-11 Tom Tromey <tromey@adacore.com> * fbsd-tdep.c (fbsd_core_info_proc_status): Cast result of bfd_get_signed_8. Change-Id: Ic015f5fd3d88da6b5da8f7b4e1d11d5c981333db
2019-12-11Implement 'print -raw-values' and 'set print raw-values on|off'Philippe Waroquiers9-14/+110
The option framework documentation was speaking about a 'print -raw' option, but this option does not exist. This patch implements -raw-values option that tells to ignore the active pretty printers when printing a value. As we already have -raw-frame-arguments, I thought -raw-values was more clear, in particular to differentiate set print raw-values and set print raw-frame-arguments. gdb/doc/ChangeLog 2019-12-11 Philippe Waroquiers <philippe.waroquiers@skynet.be> * gdb.texinfo (Command Options): Use -p and -pretty in the example, as -r is ambiguous. Update the print - TAB TAB completion result. (Data): Document new option -raw-values. Use -p and -pretty in the example, as -r is ambiguous. (Print Settings): Document set print raw values. (Pretty-Printer Commands): Document interaction between enabled pretty printers and -raw-values/-raw-frame-arguments. gdb/ChangeLog 2019-12-11 Philippe Waroquiers <philippe.waroquiers@skynet.be> * NEWS: Document -raw-values option and the related setting commands. * printcmd.c (print_command_parse_format): Do not set opts->raw off, only set it on when /r is given. * valprint.c (value_print_option_defs): New element raw-values. * Makefile.in: Add the new file. gdb/testsuite/ChangeLog 2019-12-11 Philippe Waroquiers <philippe.waroquiers@skynet.be> * gdb.base/options.exp: Add -raw-values in the print completion list. * gdb.python/py-prettyprint.exp: Add tests for -raw-values.
2019-12-10Minor fix to gdb.prompt documentationTom Tromey2-3/+7
I noticed that an example in the gdb.prompt documentation used the wrong kind of quotes -- because it is code, it should use a plain ASCII quotation mark. I also slightly shortened the sample text here, so it would more clearly fit on a single line. gdb/doc/ChangeLog 2019-12-10 Tom Tromey <tom@tromey.com> * python.texi (gdb.prompt): Use correct quotes in example. Shorten sample text. Change-Id: I4153928c0d88001244ad410f3943c952a6ebfeb1
2019-12-10OpenMP parallel region scope testsKevin Buettner3-0/+461
Add tests which check for accessibility of variables from within various OpenMP parallel regions. Tested on Fedora 27, 28, 29, 30, and 31. I also tested with my OpenMP work on Fedora 30. The test has been annotated with setup_xfail and setup_kfail statements so that there are no unexpected failures on any of these platforms when using gcc. Better still, for my own testing anyway, is that there are also no XPASSes or KPASSes either. So, regardless of platform, when using gcc, and regardless of whether my (not yet public) OpenMP work is used, seeing a FAIL indicates a real problem. Fedora 27 results: # of expected passes 85 # of expected failures 65 (Note: I have not retested F27 since v1 of the patch; it's possible that the numbers will be slightly different for v2.) Fedora 28, 29, 30 results: # of expected passes 131 # of expected failures 4 # of known failures 16 Fedora 30, 31 results w/ my OpenMP work: # of expected passes 151 The above results all use gcc, either the system gcc or a development gcc (when testing against my OpenMP work in GDB). I've also tested with clang 9.0.0 and icc 19.0.5.281 20190815 on Fedora 31. Fedora 31, clang: FAIL: gdb.threads/omp-par-scope.exp: single_scope: first thread: print s1 FAIL: gdb.threads/omp-par-scope.exp: single_scope: first thread: print s3 FAIL: gdb.threads/omp-par-scope.exp: single_scope: first thread: print i1 FAIL: gdb.threads/omp-par-scope.exp: single_scope: first thread: print i3 FAIL: gdb.threads/omp-par-scope.exp: single_scope: second thread: print s1 FAIL: gdb.threads/omp-par-scope.exp: single_scope: second thread: print s3 FAIL: gdb.threads/omp-par-scope.exp: single_scope: second thread: print i1 FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print i02 FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print i11 FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print i12 FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print i22 FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print file_scope_var FAIL: gdb.threads/omp-par-scope.exp: multi_scope: second thread: print i11 FAIL: gdb.threads/omp-par-scope.exp: multi_scope: second thread: print file_scope_var FAIL: gdb.threads/omp-par-scope.exp: multi_scope: after parallel: print file_scope_var FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 1st stop: print file_scope_var FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 1st stop: print num FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 1st stop: print l FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 1st stop: print k FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 2nd stop: print file_scope_var FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 2nd stop: print num FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print file_scope_var FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print num FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print l FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print k FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 4th stop: print file_scope_var FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 4th stop: print num FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: outer_threads: outer stop: print file_scope_var FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: outer_threads: outer stop: print i FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: outer_threads: outer stop: print j Fedora 31, icc: FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print i12 FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print i22 FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 1st thread: print s1 FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 1st thread: print i FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 1st thread: print j FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 2nd thread: print s1 FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 2nd thread: print i FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 2nd thread: print j FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 2nd thread: print k FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 2nd thread: print z FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 1st thread: print s1 FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 1st thread: print i FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 1st thread: print j FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 2nd thread: print s1 FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 2nd thread: print i FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 2nd thread: print j FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 2nd thread: print k FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 2nd thread: print z FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 1st stop: print l FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 1st stop: print k FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print l FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print k For both clang and icc, it turns out that there are some problems with the DWARF that these compilers generate. Of the two, icc does at least nest the subprogram of the outlined function representing the parallel region within the function that it's defined, but does not handle inner scopes if they exist. clang places the subprogram for the outlined function at the same level as the containing function, so variables declared within the function aren't visible at all. I could call setup_xfail to avoid FAILs for clang and icc also, but I don't want to further complicate the test. gdb/testsuite/ChangeLog: * gdb.threads/omp-par-scope.c: New file. * gdb/threads/omp-par-scope.exp: New file. Change-Id: Icb9c991730d84ca7509380af817dfcc778e764ea
2019-12-10Add gdb_caching_proc support_nested_function_tests to lib/gdb.expKevin Buettner2-3/+22
This commit adds the gdb_caching_proc, support_nested_function_tests, to lib/gdb.exp. It tests to see whether or not the C compiler has support for nested function calls. gdb/testsuite/ChangeLog: * lib/gdb.exp (support_nested_function_tests): New proc. Change-Id: Ic2c93bc4cc200e07e104a2398f89a9c0514bdc75
2019-12-10Add gdb_compile_openmp to lib/gdb.expKevin Buettner2-2/+19
gdb/testsuite/ChangeLog: * lib/gdb.exp (gdb_compile_openmp): New proc. (build_executable_from_specs): Add an "openmp" option. (gdb_compile_pthreads): Add non-executable case. Change-Id: I94048b8b0940c707ce0529a6bcfa6e4eace49101
2019-12-10Suppress the "unused function" warning for select_strerror_rChristian Biesinger2-0/+13
We only ever use one of the two overloads, so to avoid breaking -Werror builds, supress the warning. gdb/ChangeLog: 2019-12-10 Christian Biesinger <cbiesinger@google.com> * gdbsupport/safe-strerror.c: Supress the unused function warning for select_strerror_r. Change-Id: I344869a382bb36fe181b5b2a31838d1d20f58169
2019-12-10Replace the remaining uses of strerror with safe_strerrorChristian Biesinger15-65/+66
To do that, this patch makes IPA compile safe-strerror as well. Because it doesn't use Gnulib, it calls the Glibc version of strerror_r directly. Consequently this patch also removes the configure checks for strerror. gdb/ChangeLog: 2019-12-10 Christian Biesinger <cbiesinger@google.com> * config.in: Regenerate. * configure: Regenerate. * gdbsupport/agent.c (gdb_connect_sync_socket): Call safe_strerror instead of strerror. * gdbsupport/common.m4: Don't check for strerror. * gdbsupport/safe-strerror.c: Support both the glibc version of strerror_r and the XSI version. gdb/gdbserver/ChangeLog: 2019-12-10 Christian Biesinger <cbiesinger@google.com> * Makefile.in: Add safe-strerror.c to gdbreplay and IPA, and change UNDO_GNULIB_CFLAGS to undo strerror_r instead of strerror. * config.in: Regenerate. * configure: Regenerate. * configure.ac: Don't check for strerror. * linux-i386-ipa.c (initialize_fast_tracepoint_trampoline_buffer): Call safe_strerror instead of strerror. * server.h (strerror): Remove this now-unnecessary declaration. * tracepoint.c (init_named_socket): Call safe_strerror instead of strerror. (gdb_agent_helper_thread): Likewise. * utils.c (perror_with_name): Likewise. Change-Id: I74848f072dcde75cb55c435ef9398dc8f958cd73
2019-12-10Normalize Ada ptype to use a single "?"Tom Tromey8-5/+171
Sometimes -- notably with unchecked unions -- the Ada "ptype" code will print a "?" or "??" to indicate something unknown. The choice of what was printed was somewhat arbitrary, and in one case, Ada would print an empty string rather than "?". This patch normalizes the Ada code to use "?" rather than an empty string or "??". My reasoning here is that a single question mark is enough to convey unknown-ness. gdb/ChangeLog 2019-12-10 Tom Tromey <tromey@adacore.com> * ada-typeprint.c (print_choices): Use a single "?". (print_variant_part): Print "?" if the discriminant name is not known. gdb/testsuite/ChangeLog 2019-12-10 Tom Tromey <tromey@adacore.com> * gdb.ada/unchecked_union.exp: New file. * gdb.ada/unchecked_union/pck.adb: New file. * gdb.ada/unchecked_union/pck.ads: New file. * gdb.ada/unchecked_union/unchecked_union.adb: New file. * gdb-utils.exp (string_to_regexp): Also quote "?". Change-Id: I3403040780a155ffa2c44c8e6a04ba86bc810e29
2019-12-09Fix scripted probe breakpointsGeorge Barrett10-21/+141
The documentation for make-breakpoint from the Guile API and the `spec' variant of the gdb.Breakpoint constructor from the Python API state that the format acceptable for location strings is the same as that accepted by the break command. However, using the -probe qualifier at the beginning of the location string causes a GDB internal error as it attempts to decode a probe location in the wrong code path. Without this functionality, there doesn't appear to be another way to set breakpoints on probe points from Python or Guile scripts. This patch introduces a new helper function that returns a breakpoint_ops instance appropriate for a parsed location and updates the Guile and Python bindings to use said function, rather than the current hard-coded use of bkpt_breakpoint_ops. Since this logic is duplicated in the handling of the `break' and `trace' commands, those are also updated to call into the new helper function. gdb/ChangeLog: 2019-12-10 George Barrett <bob@bob131.so> Fix scripted probe breakpoints. * breakpoint.c (tracepoint_probe_breakpoint_ops): Move declaration forward. (breakpoint_ops_for_event_location_type) (breakpoint_ops_for_event_location): Add function definitions. (break_command_1, trace_command): Use breakpoint_ops_for_event_location. * breakpoint.h (breakpoint_ops_for_event_location): Add function declarations. * guile/scm-breakpoint.c (gdbscm_register_breakpoint_x): Use breakpoint_ops_for_event_location. * python/py-breakpoint.c (bppy_init): Use breakpoint_ops_for_event_location. gdb/testsuite/ChangeLog: 2019-12-10 George Barrett <bob@bob131.so> Test scripted probe breakpoints. * gdb.guile/scm-breakpoint.c (main): Add probe point. * gdb.python/py-breakpoint.c (main): Likewise. * gdb.guile/scm-breakpoint.exp (test_bkpt_probe): Add probe specifier test. * gdb.python/py-breakpoint.exp (test_bkpt_probe): Likewise.
2019-12-09gdb: rank an lvalue argument incompatible for an rvalue parameterTankut Baris Aktemur5-5/+30
Passing an lvalue argument to a function that takes an rvalue parameter is not allowed per C++ rules. Consider this function: int g (int &&x) { return x; } Calling g as in int i = 5; int j = g (i); is illegal. For instance, GCC 9.2.1 yields ~~~ test.cpp: In function ‘int main()’: test.cpp:6:14: error: cannot bind rvalue reference of type ‘int&&’ to lvalue of type ‘int’ 6 | int j = g (i); | ^ ~~~ GDB currently allows this function call: ~~~ (gdb) print g(i) $1 = 5 ~~~ Fix this by ranking an lvalue argument incompatible with an rvalue parameter. The behavior after this patch is: ~~~ (gdb) print g(i) Cannot resolve function g to any overloaded instance ~~~ Tested with GCC 9.2.1. gdb/ChangeLog: 2019-12-09 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * gdbtypes.c (rank_one_type): Return INCOMPATIBLE_TYPE_BADNESS when ranking an lvalue argument for an rvalue parameter. gdb/testsuite/ChangeLog: 2019-12-09 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * gdb.cp/rvalue-ref-overload.cc (g): New function that takes an rvalue parameter. * gdb.cp/rvalue-ref-overload.exp: Test calling it with an lvalue parameter. Change-Id: I4a6dfc7dac63efa1e3b9f8f391e4b736fbdccdc1
2019-12-09gdb/fortran: Improve output pattern in gdb.mi/mi-fortran-modules.expAndrew Burgess2-4/+16
Extend the output pattern in mi-fortran-modules.exp to skip some system modules that appear with versions of GFortran after 7.x.x. gdb/testsuite/ChangeLog: * gdb.mi/mi-fortran-modules.exp: Add patterns to skip system modules. Change-Id: I64aaa395e554a32e8267ffa096faee53c19c0b9e
2019-12-09gdb/testsuite: kfail some tests if using broken gccAndrew Burgess2-0/+11
In some cases the Fortran stride information generated by GCC is wrong with versions of GCC after 7.x.x. This commit adds kfails for the tests in question with known bad versions of gcc. The bug has been reported to GCC here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92775 gdb/testsuite/ChangeLog: * gdb.fortran/derived-type-striding.exp: KFAIL if we are using a broken version of GCC. Change-Id: Iaef08e5e2c87ab3d6983b88f749d40e01aea2bc6
2019-12-09gdb/testsuite/fortran: Fix info-modules/info-types for gfortran 8+Andrew Burgess4-140/+648
The gdb.fortran/info-modules.exp and gdb.fortran/info-types.exp tests are failing on versions of gfortran after 7.3 due to the inclusion of extra "system" modules and type that were not being matched by the current test patterns. Rather than building increasingly complex patterns that would always be at risk of breaking with future versions of GCC I have instead added a new library that parses the output of the following commands: info types info variables info functions info modules info module functions info module variables into a data structure, the test can than run checks against the contents of this data structure. The benefit is that we can simply ignore extra results that we don't care about. There is a small risk that a bug in GDB might allow us to start reporting incorrect results in such a way that the new library will not spot the error. However, I have tried to mitigate this risk by adding extra procedures into the test library (see check_no_entry) and we can add more in future if we wanted to be even more defensive. I tested this test file with gFortran 7.3.1, 8.3.0, and 9.2.0, I now see 100% pass in all cases. gdb/testsuite/ChangeLog: * gdb.fortran/info-modules.exp: Rewrite to make use of new sym-info-cmds library. * gdb.fortran/info-types.exp: Likewise. * lib/sym-info-cmds.exp: New file. Change-Id: Iff81624f51b5afb6c95393932f3d94472d7c2970
2019-12-09gdb/darwin-nat.c: Fix template argument for scoped_restore_tmplWataru Ashihara2-1/+6
This should be the type of startup_with_shell, whose type was changed from int to bool at commit 80fd28264. This fixes the build on macOS: CXX darwin-nat.o In file included from ../../gdb/darwin-nat.c:22: In file included from ../../gdb/top.h:25: In file included from ../../gdb/value.h:23: In file included from ../../gdb/frame.h:72: In file included from ../../gdb/language.h:26: In file included from ../../gdb/symtab.h:33: ../../gdb/gdbsupport/gdb_optional.h:155:19: error: no matching constructor for initialization of 'scoped_restore_tmpl<int>' new (&m_item) T (std::forward<Args>(args)...); ^ ~~~~~~~~~~~~~~~~~~~~~~~~ ../../gdb/darwin-nat.c:1995:31: note: in instantiation of function template specialization 'gdb::optional<scoped_restore_tmpl<int> >::emplace<bool *, int>' requested here restore_startup_with_shell.emplace (&startup_with_shell, 0); ^ ../../gdb/gdbsupport/scoped_restore.h:69:3: note: candidate constructor template not viable: no known conversion from 'bool *' to 'int *' for 1st argument scoped_restore_tmpl (T *var, T2 value) ^ ../../gdb/gdbsupport/scoped_restore.h:57:3: note: candidate constructor not viable: requires single argument 'var', but 2 arguments were provided scoped_restore_tmpl (T *var) ^ ../../gdb/gdbsupport/scoped_restore.h:76:3: note: candidate constructor not viable: requires single argument 'other', but 2 arguments were provided scoped_restore_tmpl (const scoped_restore_tmpl<T> &other) ^ 1 error generated. gdb/ChangeLog 2019-12-08 Wataru Ashihara <wataash@wataash.com> * darwin-nat.c (darwin_nat_target::create_inferior): Fix template argument for scoped_restore_tmpl from bool to int. Change-Id: Ia0202efd34dbce69b6af5d035fa55ed89215138a
2019-12-08Fix inter-CU references using intra-CU form in imported-unitTom de Vries2-5/+9
When running the gdb testsuite with the cc-with-dwz board, I run into: ... Running gdb/testsuite/gdb.dwarf2/imported-unit.exp ... gdb compile failed, dwz: gdb.dwarf2/imported-unit/imported-unit: \ Couldn't find DIE referenced by DW_AT_abstract_origin cc-with-tweaks.sh: dwz did not modify gdb.dwarf2/imported-unit/imported-unit. ... The problem is that the DW_AT_abstract_origin reference here: ... <0><d2>: Abbrev Number: 2 (DW_TAG_compile_unit) <1><e6>: Abbrev Number: 4 (DW_TAG_subprogram) <e7> DW_AT_abstract_origin: <0x142> <eb> DW_AT_low_pc : 0x4004b2 <f3> DW_AT_high_pc : 0x4004c8 ... referring to a DIE in another compilation unit here: ... <0><129>: Abbrev Number: 2 (DW_TAG_compile_unit) <1><142>: Abbrev Number: 4 (DW_TAG_subprogram) <143> DW_AT_name : main <148> DW_AT_type : <0x13b> <14c> DW_AT_external : 1 ... is encoded using intra-CU reference form DW_FORM_ref4 instead of intra-CU reference DW_FORM_ref_addr: ... 4 DW_TAG_subprogram [has children] DW_AT_abstract_origin DW_FORM_ref4 DW_AT_low_pc DW_FORM_addr DW_AT_high_pc DW_FORM_addr DW_AT value: 0 DW_FORM value: 0 ... Fix this in the DWARF assembler by making all inter-CU references use the '%' label prefix. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2019-12-08 Tom de Vries <tdevries@suse.de> * gdb.dwarf2/imported-unit.exp: Fix inter-CU references. Change-Id: I690ff18c3943705ed478453531b176ff74700f3c
2019-12-07Core file build-id supportKeith Seitz9-8/+485
This patch uses new BFD support for detecting build-ids in core files. After this patch, it is possible to run gdb with only the core file, and gdb will automatically load the executable and debug info [example from tests]: $ gdb -nx -q (gdb) core-file corefile-buildid.core [New LWP 29471] Reading symbols from gdb.base/corefile-buildid/debugdir-exec/.build-id/36/fe5722c5a7ca3ac746a84e223c6a2a69193a24... Core was generated by `outputs/gdb.base/coref'. Program terminated with signal SIGABRT, Aborted. (gdb) This work is based on functionality available in Fedora originally written by Jan Kratochvil. Regression tested on buildbot. gdb/ChangeLog: 2019-12-07 Keith Seitz <keiths@redhat.com> * build-id.c (build_id_bfd_get): Permit bfd_core, too. (build_id_to_debug_bfd): Make static, rewriting to use build_id_to_bfd_suffix. (build_id_to_bfd_suffix): Copy of build_id_to_debug_bfd, adding `suffix' parameter. Append SUFFIX to file names when searching for matching files. (build_id_to_debug_bfd): Use build_id_to_bfd_suffix. (build_id_to_exec_bfd): Likewise. * build-id.h (build_id_to_debug_bfd): Clarify that function searches for BFD of debug info file. (build_id_to_exec_bfd): Declare. * corelow.c: Include build-id.h. (locate_exec_from_corefile_build_id): New function. (core_target_open): If no executable BFD is found, search for a core file BFD using build-id. gdb/testsuite/ChangeLog: 2019-12-07 Keith Seitz <keiths@redhat.com> * gdb.base/corefile-buildid-shlib-shr.c: New file. * gdb.base/corefile-buildid-shlib.c: New file. * gdb.base/corefile-buildid.c: New file. * gdb.base/corefile-buildid.exp: New file. Change-Id: I15e9e8e58f10c68b5cae55e2eba58df1e8aef529
2019-12-06Put bcache inside "namespace gdb"Christian Biesinger8-9/+36
This avoids a conflict with a system "struct bcache" on Solaris (see e.g. https://www.isi.edu/nsnam/archive/ns-users/webarch/2001/msg05393.html) Note that the Solaris conflict for now only surfaces with --enable-targets=all (which the build bot doesn't use). gdb/ChangeLog: 2019-12-06 Christian Biesinger <cbiesinger@google.com> * bcache.c: Put in namespace gdb. * bcache.h: Likewise. * gdbtypes.c (check_types_worklist): Update. (types_deeply_equal): Update. * macrotab.c (struct macro_table) <bcache>: Update. (new_macro_table): Update. * macrotab.h (struct bcache): Put this forward declaration inside namespace gdb. (new_macro_table): Update. * objfiles.h (struct objfile_per_bfd_storage) <filename_cache>: Update. <macro_cache>: Update. * psymtab.h: (psymtab_storage) <psymbol_cache>: Update. Change-Id: I843d5e91f7ccb3db6d1099a8214c15a74510256f
2019-12-06[gdb/symtab] Prefer var def over declTom de Vries4-10/+123
Consider the DWARF as generated by gcc with the tentative patch to fix gcc PR91507 - "wrong debug for completed array with previous incomplete declaration": ... <1><f4>: Abbrev Number: 2 (DW_TAG_array_type) <f5> DW_AT_type : <0xff> <f9> DW_AT_sibling : <0xff> <2><fd>: Abbrev Number: 3 (DW_TAG_subrange_type) <2><fe>: Abbrev Number: 0 <1><ff>: Abbrev Number: 4 (DW_TAG_pointer_type) <100> DW_AT_byte_size : 8 <101> DW_AT_type : <0x105> <1><105>: Abbrev Number: 5 (DW_TAG_base_type) <106> DW_AT_byte_size : 1 <107> DW_AT_encoding : 6 (signed char) <108> DW_AT_name : (indirect string, offset: 0x19f): char <1><10c>: Abbrev Number: 6 (DW_TAG_variable) <10d> DW_AT_name : zzz <111> DW_AT_decl_file : 1 <112> DW_AT_decl_line : 1 <113> DW_AT_decl_column : 14 <114> DW_AT_type : <0xf4> <118> DW_AT_external : 1 <118> DW_AT_declaration : 1 <1><118>: Abbrev Number: 2 (DW_TAG_array_type) <119> DW_AT_type : <0xff> <11d> DW_AT_sibling : <0x128> <1><12f>: Abbrev Number: 8 (DW_TAG_variable) <130> DW_AT_specification: <0x10c> <134> DW_AT_decl_line : 2 <135> DW_AT_decl_column : 7 <136> DW_AT_type : <0x118> <13a> DW_AT_location : 9 byte block: 3 30 10 60 0 0 0 0 0 (DW_OP_addr: 601030) ... The DWARF will result in two entries in the symbol table, a decl with type char *[] and a def with type char*[2]. When trying to print the value of zzz: ... $ gdb a.spec.out -batch -ex "p zzz" ... the decl (rather than the def) will be found in the symbol table, which is missing the location information, and consequently we get: ... $1 = 0x601030 <zzz> ... [ There is a fallback mechanism that finds the address of the variable in the minimal symbol table, but that's not used here, because the type of the decl does not specify a size. We could use the symbol size here to get the size of the type, but that's currently not done: PR exp/24989. Still, fixing that PR would not fix the generic case, where minimal symbol info is not available. ] Fix this by preferring defs over decls when searching in the symbol table. Build and reg-tested on x86_64-linux. gdb/ChangeLog: 2019-12-06 Tom de Vries <tdevries@suse.de> PR symtab/24971 * block.c (best_symbol, better_symbol): New function. (block_lookup_symbol_primary, block_lookup_symbol): Prefer def over decl. gdb/testsuite/ChangeLog: 2019-12-06 Tom de Vries <tdevries@suse.de> * gdb.dwarf2/varval.exp: Add decl before def test. Change-Id: Id92326cb8ef9903b121ef9e320658eb565d0f5a9
2019-12-06gdb/testsuite: do minor clean-up in gdb.cp/rvalue-ref-overload.expTankut Baris Aktemur2-9/+9
Simplify the expected test outputs. This is a minor cleanup; no functional change is intended. gdb/testsuite/ChangeLog: 2019-12-06 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * gdb.cp/rvalue-ref-overload.exp: Minor cleanup. Change-Id: Ie760a2856cae3be0eeed5496765a5f1cd102d6b7
2019-12-06gdb: fix overload resolution for see-through referencesTankut Baris Aktemur6-2/+29
The overload resolution mechanism assigns badness values to the necessary conversions to be made on types to pick a champion. A badness value consists of a "rank" that scores the conversion and a "subrank" to differentiate conversions of the same kind. An auxiliary function, 'sum_ranks', is used for adding two badness values. In all of its uses, except two, 'sum_ranks' is used for populating the subrank of a badness value. The two exceptions are in 'rank_one_type': ~~~ /* See through references, since we can almost make non-references references. */ if (TYPE_IS_REFERENCE (arg)) return (sum_ranks (rank_one_type (parm, TYPE_TARGET_TYPE (arg), NULL), REFERENCE_CONVERSION_BADNESS)); if (TYPE_IS_REFERENCE (parm)) return (sum_ranks (rank_one_type (TYPE_TARGET_TYPE (parm), arg, NULL), REFERENCE_CONVERSION_BADNESS)); ~~~ Here, the result of a recursive call is combined with REFERENCE_CONVERSION_BADNESS. This leads to the problem of over-punishment by combining two ranks. Consider this: void an_overloaded_function (const foo &); void an_overloaded_function (const foo &&); ... foo arg; an_overloaded_function(arg); When ranking 'an_overloaded_function (const foo &)', the badness values REFERENCE_CONVERSION_BADNESS and CV_CONVERSION_BADNESS are combined, whereas 'rank_one_type' assigns only the REFERENCE_CONVERSION_BADNESS value to 'an_overloaded_function (const foo &&)' (there is a different execution flow for that). This yields in GDB picking the latter function as the overload champion instead of the former. In fact, the 'rank_one_type' function should have given 'an_overloaded_function (const foo &)' the CV_CONVERSION_BADNESS value, with the see-through referencing increasing the subrank a little bit. This can be achieved by introducing a new badness value, REFERENCE_SEE_THROUGH_BADNESS, which bumps up the subrank only, and using it in the two "exceptional" cases of 'sum_ranks'. gdb/ChangeLog: 2019-12-06 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * gdbtypes.h: Define the REFERENCE_SEE_THROUGH_BADNESS value. * gdbtypes.c (rank_one_type): Use REFERENCE_SEE_THROUGH_BADNESS for ranking see-through reference cases. gdb/testsuite/ChangeLog: 2019-12-06 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * gdb.cp/rvalue-ref-overload.cc: Add a case that involves both CV and reference conversion for overload resolution. * gdb.cp/rvalue-ref-overload.exp: Test it. Change-Id: I39ae6505ab85ad0bd21915368c82540ceeb3aae9
2019-12-06Fix crash when command arg is missing in faas/taas/tfaas commands.Philippe Waroquiers6-1/+22
GDB crashes when doing: (gdb) faas Aborted Do the needed check to avoid crashing. gdb/ChangeLog 2019-12-06 Philippe Waroquiers <philippe.waroquiers@skynet.be> * stack.c (faas_command): Check a command is provided. * thread.c (taas_command, tfaas_command): Likewise. gdb/testsuite/ChangeLog 2019-12-06 Philippe Waroquiers <philippe.waroquiers@skynet.be> * gdb.threads/pthreads.exp: Test taas and tfaas without command. * gdb.base/frameapply.exp: Test faas without command.
2019-12-05Fix leaks when pruning inferiors.Philippe Waroquiers2-6/+8
Valgrind detects various inferior related leaks, such as: ==31877== 5,530 (56 direct, 5,474 indirect) bytes in 1 blocks are definitely lost in loss record 7,131 of 7,355 ==31877== at 0x4C2E18C: calloc (vg_replace_malloc.c:760) ==31877== by 0x23E580: xcalloc (alloc.c:100) ==31877== by 0x4794A9: xcnewvec<void*> (poison.h:158) ==31877== by 0x4794A9: registry_alloc_data(registry_data_registry*, registry_fields*) (registry.c:51) ==31877== by 0x3A537C: inferior_alloc_data (inferior.c:43) ==31877== by 0x3A537C: inferior::inferior(int) (inferior.c:92) ==31877== by 0x3A5426: add_inferior_silent(int) (inferior.c:98) ==31877== by 0x3A5530: add_inferior(int) (inferior.c:122) ... Origin of the leaks is in prune_inferiors: prune_inferiors is first removing the inferior to prune from the inferior list, then calls delete_inferior. But delete_inferior will only really destroy the inferior when it finds it into the inferior list. As delete_inferior is removing the inferior to delete from the inferior list, ensure prune_inferiors only calls delete_inferior, without touching the inferior list. gdb/ChangeLog 2019-12-05 Philippe Waroquiers <philippe.waroquiers@skynet.be> * inferior.c (prune_inferiors): Only call delete_inferior. Do not modify the inferior list.
2019-12-05Remove gdbarch parameter of lookup_typenameSimon Marchi13-69/+51
I noticed that the gdbarch parameter of lookup_typename was unused, so I removed it (as well as from lookup_signed_typename and lookup_unsigned_typename) and updated all callers. Tested by rebuilding. gdb/ChangeLog: * c-exp.y: Update calls to lookup_typename, lookup_signed_typename and lookup_unsigned_typename. * c-lang.c (evaluate_subexp_c): Likewise. * cp-namespace.c (cp_lookup_symbol_imports_or_template): Likewise. * eval.c (binop_promote): Likewise. * gdbtypes.c (lookup_typename): Remove gdbarch parameter. (lookup_unsigned_typename): Likewise. (lookup_signed_typename): Likewise. * gdbtypes.h (lookup_unsigned_typename): Likewise. (lookup_signed_typename): Likewise. (lookup_typename): Likewise. * guile/scm-type.c (tyscm_lookup_typename): Update calls to lookup_typename, lookup_signed_typename, lookup_unsigned_typename. * m2-exp.y: Likewise. * printcmd.c (printf_wide_c_string): Likewise. (ui_printf): Likewise. * python/py-type.c (typy_lookup_typename): Likewise. * python/py-xmethods.c (python_xmethod_worker::invoke): Likewise. * rust-exp.y: Likewise.
2019-12-04Fix (most) OpenBSD link errorsChristian Biesinger2-2/+8
This fixes these errors: ld: error: undefined symbol: x86_stopped_by_hw_breakpoint() >>> referenced by x86-nat.h:109 (../../gdb/x86-nat.h:109) >>> amd64-obsd-nat.o:(x86_nat_target<obsd_nat_target>::stopped_by_hw_breakpoint()) ld: error: undefined symbol: x86_can_use_hw_breakpoint(bptype, int, int) >>> referenced by x86-nat.h:76 (../../gdb/x86-nat.h:76) >>> amd64-obsd-nat.o:(x86_nat_target<obsd_nat_target>::can_use_hw_breakpoint(bptype, int, int)) ld: error: undefined symbol: x86_insert_hw_breakpoint(gdbarch*, bp_target_info*) >>> referenced by x86-nat.h:93 (../../gdb/x86-nat.h:93) >>> amd64-obsd-nat.o:(x86_nat_target<obsd_nat_target>::insert_hw_breakpoint(gdbarch*, bp_target_info*)) ld: error: undefined symbol: x86_remove_hw_breakpoint(gdbarch*, bp_target_info*) >>> referenced by x86-nat.h:97 (../../gdb/x86-nat.h:97) >>> amd64-obsd-nat.o:(x86_nat_target<obsd_nat_target>::remove_hw_breakpoint(gdbarch*, bp_target_info*)) ld: error: undefined symbol: x86_remove_watchpoint(unsigned long, int, target_hw_bp_type, expression*) >>> referenced by x86-nat.h:89 (../../gdb/x86-nat.h:89) >>> amd64-obsd-nat.o:(x86_nat_target<obsd_nat_target>::remove_watchpoint(unsigned long, int, target_hw_bp_type, expression*)) ld: error: undefined symbol: x86_insert_watchpoint(unsigned long, int, target_hw_bp_type, expression*) >>> referenced by x86-nat.h:84 (../../gdb/x86-nat.h:84) >>> amd64-obsd-nat.o:(x86_nat_target<obsd_nat_target>::insert_watchpoint(unsigned long, int, target_hw_bp_type, expression*)) ld: error: undefined symbol: x86_stopped_by_watchpoint() >>> referenced by x86-nat.h:100 (../../gdb/x86-nat.h:100) >>> amd64-obsd-nat.o:(x86_nat_target<obsd_nat_target>::stopped_by_watchpoint()) ld: error: undefined symbol: x86_stopped_data_address(unsigned long*) >>> referenced by x86-nat.h:103 (../../gdb/x86-nat.h:103) >>> amd64-obsd-nat.o:(x86_nat_target<obsd_nat_target>::stopped_data_address(unsigned long*)) ld: error: undefined symbol: x86_region_ok_for_hw_watchpoint(unsigned long, int) >>> referenced by x86-nat.h:79 (../../gdb/x86-nat.h:79) >>> amd64-obsd-nat.o:(x86_nat_target<obsd_nat_target>::region_ok_for_hw_watchpoint(unsigned long, int)) and ld: error: undefined symbol: x86_dr_insert_watchpoint(x86_debug_reg_state*, target_hw_bp_type, unsigned long, int) >>> referenced by x86-nat.c:156 (../../gdb/x86-nat.c:156) >>> x86-nat.o:(x86_insert_watchpoint(unsigned long, int, target_hw_bp_type, expression*)) ld: error: undefined symbol: x86_dr_remove_watchpoint(x86_debug_reg_state*, target_hw_bp_type, unsigned long, int) >>> referenced by x86-nat.c:169 (../../gdb/x86-nat.c:169) >>> x86-nat.o:(x86_remove_watchpoint(unsigned long, int, target_hw_bp_type, expression*)) ld: error: undefined symbol: x86_dr_region_ok_for_watchpoint(x86_debug_reg_state*, unsigned long, int) >>> referenced by x86-nat.c:181 (../../gdb/x86-nat.c:181) >>> x86-nat.o:(x86_region_ok_for_hw_watchpoint(unsigned long, int)) ld: error: undefined symbol: x86_dr_stopped_data_address(x86_debug_reg_state*, unsigned long*) >>> referenced by x86-nat.c:194 (../../gdb/x86-nat.c:194) >>> x86-nat.o:(x86_stopped_data_address(unsigned long*)) ld: error: undefined symbol: x86_dr_stopped_by_watchpoint(x86_debug_reg_state*) >>> referenced by x86-nat.c:206 (../../gdb/x86-nat.c:206) >>> x86-nat.o:(x86_stopped_by_watchpoint()) ld: error: undefined symbol: x86_dr_insert_watchpoint(x86_debug_reg_state*, target_hw_bp_type, unsigned long, int) >>> referenced by x86-nat.c:219 (../../gdb/x86-nat.c:219) >>> x86-nat.o:(x86_insert_hw_breakpoint(gdbarch*, bp_target_info*)) ld: error: undefined symbol: x86_dr_remove_watchpoint(x86_debug_reg_state*, target_hw_bp_type, unsigned long, int) >>> referenced by x86-nat.c:233 (../../gdb/x86-nat.c:233) >>> x86-nat.o:(x86_remove_hw_breakpoint(gdbarch*, bp_target_info*)) ld: error: undefined symbol: x86_dr_stopped_by_hw_breakpoint(x86_debug_reg_state*) >>> referenced by x86-nat.c:269 (../../gdb/x86-nat.c:269) >>> x86-nat.o:(x86_stopped_by_hw_breakpoint()) It does not fix: ld: error: can't create dynamic relocation R_X86_64_64 against symbol: __gmp_binvert_limb_table in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output >>> defined in /usr/local/lib/libgmp.a(mp_minv_tab.o) >>> referenced by tmp-dive_1.s >>> dive_1.o:(__gmpn_divexact_1) in archive /usr/local/lib/libgmp.a ld: error: can't create dynamic relocation R_X86_64_64 against symbol: __gmp_binvert_limb_table in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output >>> defined in /usr/local/lib/libgmp.a(mp_minv_tab.o) >>> referenced by tmp-bdiv_q_1.s >>> bdiv_q_1.o:(__gmpn_bdiv_q_1) in archive /usr/local/lib/libgmp.a ld: error: can't create dynamic relocation R_X86_64_64 against symbol: __gmpn_invert_limb_table in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output >>> defined in /usr/local/lib/libgmp.a(invert_limb_table.o) >>> referenced by tmp-invert_limb.s >>> invert_limb.o:(__gmpn_invert_limb) in archive /usr/local/lib/libgmp.a gdb/ChangeLog: 2019-12-04 Christian Biesinger <cbiesinger@google.com> * configure.nat (obsd64): Add missing files x86-nat.o and nat/x86-dregs.o. Change-Id: I4a443c0cf805efd7b45feaabd729a01b07772724
2019-12-04Use metadata style in a few more placesTom Tromey5-15/+24
I happened to find a few more spots that should use metadata style, but do not. I missed these in my earlier search somehow. This patch also adds gettext markup in a couple of spots where it was missing. gdb/ChangeLog 2019-12-04 Tom Tromey <tom@tromey.com> * valprint.c (val_print_string): Use metadata_style. * go-valprint.c (print_go_string): Use metadata style. * p-valprint.c (pascal_object_print_static_field): Use metadata style. * cp-valprint.c (cp_print_static_field): Use metadata style. Change-Id: Id82ca2aa306c6694b111d5c92dfa6f0cce919ebf
2019-12-04gdb/testsuite: Use -J option when compiling Fortran testsAndrew Burgess3-1/+18
When compiling Fortran tests (e.g. gdb.fortran/info-modules.exp), the Fotran compile produces .mod files. These files contain details of compiled modules that are then consumed by the compiler when compiling other files that USE a module. Currently the compiler writes the .mod files into its current directory, so for us this turns out to be 'build/gdb/testsuite/'. This means that .mod files can be shared between tests, which seems against the spirit of the GDB testsuite; source files should be compiled fresh for each test. This commit adds the -J option to the compiler flags whenever we compile a Fortran file, this option tells the compiler where to write, and look for, .mod files. After this commit there was one Fortran test that needed fixing, with that fix in place all of the Fortran tests pass again, but now the .mod files are now produced in the per-test output directories. gdb/testsuite/ChangeLog: * lib/gdb.exp (gdb_compile): Add -J compiler option when building Fortran tests. * gdb.mi/mi-fortran-modules.exp: Compile source files in correct order. Change-Id: I99444cf22d80e320093d3f3ed9abb8825f378e0b
2019-12-04gdb/fortran: Support for single/double type modifiersAndrew Burgess4-3/+52
Extend the Fortran parser to support 'single precision' and 'double precision' types as well 'single complex' and 'double complex' types. gdb/ChangeLog: * f-exp.y (COMPLEX_KEYWORD, SINGLE, DOUBLE, PRECISION): New tokens. (typebase): New patterns for complex, single/double precision, and single/double complex. (f77_keywords): Change token for complex keyword, and add single, double, and precision keywords. gdb/testsuite/ChangeLog: * gdb.fortran/type-kinds.exp (test_cast_1_to_type_kind): Handle casting to type with no kind specified. (test_basic_parsing_of_type_kinds): Additional tests for types with no kind specified, and add tests for single/double precision/complex types. Change-Id: I9c82f4d392c58607747bd08862c1ee330723a1ba
2019-12-04Fix doc of AVR-specific command "info io_registers"Simon Marchi2-1/+6
Running the selftests on an all-targets build, I get: Running selftest help_doc_invariants. help doc broken invariant: command 'info io_registers' help doc first line is not terminated with a '.' character Self test failed: self-test failed at /home/simark/src/binutils-gdb/gdb/unittests/help-doc-selftests.c:95 Add a period at the end of the doc of that command, and make it a bit nicer in general. gdb/ChangeLog: * avr-tdep.c (_initialize_avr_tdep): Improve help of command "info io_registers".
2019-12-04Fix regcache::cooked_read_test selftest for mepSimon Marchi2-0/+6
When running the regcache::cooked_read_test selftest in an all targets build, I get the following internal error: /home/simark/src/binutils-gdb/gdb/thread.c:95: internal-error: thread_info* inferior_thread(): Assertion `tp' failed. The stack trace is the followiing: #9 0x000055fe25584a52 in internal_error (file=0x55fe27a25fe0 "/home/simark/src/binutils-gdb/gdb/thread.c", line=95, fmt=0x55fe27a25c80 "%s: Assertion `%s' failed.") at /home/simark/src/binutils-gdb/gdb/gdbsupport/errors.c:55 #10 0x000055fe260674bc in inferior_thread () at /home/simark/src/binutils-gdb/gdb/thread.c:95 #11 0x000055fe25c62f0f in get_current_regcache () at /home/simark/src/binutils-gdb/gdb/regcache.c:372 #12 0x000055fe2594fcf1 in current_options () at /home/simark/src/binutils-gdb/gdb/mep-tdep.c:873 #13 0x000055fe2594ff08 in mep_register_name (gdbarch=0x62100056f510, regnr=152) at /home/simark/src/binutils-gdb/gdb/mep-tdep.c:958 #14 0x000055fe25950112 in mep_register_reggroup_p (gdbarch=0x62100056f510, regnum=152, group=0x55fe2924d540 <save_group>) at /home/simark/src/binutils-gdb/gdb/mep-tdep.c:1029 #15 0x000055fe2555ad87 in gdbarch_register_reggroup_p (gdbarch=0x62100056f510, regnum=152, reggroup=0x55fe2924d540 <save_group>) at /home/simark/src/binutils-gdb/gdb/gdbarch.c:3622 #16 0x000055fe25c61d45 in reg_buffer::save(gdb::function_view<register_status (int, unsigned char*)>) (this=0x7ffc61a0ed90, cooked_read=...) at /home/simark/src/binutils-gdb/gdb/regcache.c:247 #17 0x000055fe2552ac60 in readonly_detached_regcache::readonly_detached_regcache(gdbarch*, gdb::function_view<register_status (int, unsigned char*)>) (this=0x7ffc61a0ed90, gdbarch=0x62100056f510, cooked_read=...) at /home/simark/src/binutils-gdb/gdb/regcache.h:444 #18 0x000055fe25c61867 in readonly_detached_regcache::readonly_detached_regcache (this=0x7ffc61a0ed90, src=...) at /home/simark/src/binutils-gdb/gdb/regcache.c:212 #19 0x000055fe25c6a5ca in selftests::cooked_read_test (gdbarch=0x62100056f510) at /home/simark/src/binutils-gdb/gdb/regcache.c:1613 The problems is that mep's code ends up calling inferior_thread, which calls find_thread_ptid. find_thread_ptid searches for a thread by ptid in the thread list of the inferior that is expected to contain that thread. However, the thread list of the mock inferior set up in cooked_read_test is never initialized. So find_thread_ptid doesn't find the thread, which is an unexpected situation for inferior_thread. This is failing since this commit: 080363310650c93ad8e93018bcb6760ba5d32d1c Per-inferior thread list, thread ranges/iterators, down with ALL_THREADS, etc. Fix it by putting the mock thread in the thread list of the mock inferior in cooked_read_test. gdb/ChangeLog: * regcache.c (cooked_read_test): Initialize thread list of mock_inferior.
2019-12-04Remove unused includes in aarch64-linux-tdep.cSimon Marchi2-5/+5
include-what-you-use reports: ../../../src/binutils-gdb/gdb/aarch64-linux-tdep.c should remove these lines: - #include "arch-utils.h" // lines 24-24 - #include "auxv.h" // lines 48-48 - #include "cli/cli-utils.h" // lines 39-39 - #include "elf/common.h" // lines 49-49 - #include "inferior.h" // lines 35-35 Add an include for "target/target.h", otherwise target_read_memory isn't found. gdb/ChangeLog: * aarch64-linux-tdep.c: Remove includes.
2019-12-04Remove unused includes in aarch64-tdep.cSimon Marchi2-7/+4
include-what-you-use reports: ../../../src/binutils-gdb/gdb/aarch64-tdep.c should remove these lines: - #include "ax.h" // lines 45-45 - #include "elf-bfd.h" // lines 52-52 - #include "elf/aarch64.h" // lines 53-53 - #include "infcall.h" // lines 44-44 - #include "inferior.h" // lines 24-24 - #include "language.h" // lines 43-43 gdb/ChangeLog: * aarch64-tdep.c: Remove includes.
2019-12-04Compare iterators, not values, in filtered_iterator::operator{==,!=}Simon Marchi4-2/+176
The == and != operators on filtered_iterator are not doing the right thing, they compare values pointed by the wrapped iterators instead of comparing the iterators themselves. As a result, operator== will return true if the two iterators point to two equal values at different positions. operator!= will fail similarly. Also, this causes it to deference past-the-end iterators when doing. For example, in for (iter = ...; iter != end_iter; ++iter) the != comparison dereferences end_iter. I don't think this should happen. I don't think it's a problem today, given that we only use filtered_iterator to wrap linked lists of threads and inferiors. Dereferencing past-the-end iterators of these types is not fatal, it just returns NULL, which is not a value we otherwise find in the lists. But in other contexts, it could become problematic. I have added a simple self test that fails without the fix applied. gdb/ChangeLog: * filtered-iterator.h (filtered_iterator) <operator==, operator!=>: Compare wrapped iterators, not wrapped pointers. * Makefile.in (SUBDIR_UNITTESTS_SRCS): Add unittests/filtered_iterator-selftests.c. * unittests/filtered_iterator-selftests.c: New file.
2019-12-04Add bit-field test for scalar_storage_orderTom Tromey3-3/+11
This adds a bit-field test for scalar_storage_order. gdb/testsuite/ChangeLog 2019-12-04 Tom Tromey <tromey@adacore.com> * gdb.base/endianity.c (struct other) <x>: New field. (main): Initialize it. * gdb.base/endianity.exp: Update. Change-Id: I9e07d1b3e08e7c3384832b68ef286afe1d11479a
2019-12-04Propagate endianity to subrange typesTom Tromey7-0/+138
A subrange type should inherit its endianity from its base type. gdb/ChangeLog 2019-12-04 Tom Tromey <tromey@adacore.com> * gdbtypes.c (create_range_type): Inherit endianity from base type. gdb/testsuite/ChangeLog 2019-12-04 Tom Tromey <tromey@adacore.com> * gdb.ada/scalar_storage/storage.adb: New file. * gdb.ada/scalar_storage/pck.adb: New file. * gdb.ada/scalar_storage/pck.ads: New file. * gdb.ada/scalar_storage.exp: New file. Change-Id: I2998ab919dc28aeff097763c4242f9bfb90823a3
2019-12-04Remove gdbarch_bits_big_endianTom Tromey13-55/+37
From what I can tell, set_gdbarch_bits_big_endian has never been used. That is, all architectures since its introduction have simply used the default, which is simply check the architecture's byte-endianness. Because this interferes with the scalar_storage_order code, this patch removes this gdbarch setting entirely. In some places, type_byte_order is used rather than the plain gdbarch. gdb/ChangeLog 2019-12-04 Tom Tromey <tromey@adacore.com> * ada-lang.c (decode_constrained_packed_array) (ada_value_assign, value_assign_to_component): Update. * dwarf2loc.c (rw_pieced_value, access_memory) (dwarf2_compile_expr_to_ax): Update. * dwarf2read.c (dwarf2_add_field): Update. * eval.c (evaluate_subexp_standard): Update. * gdbarch.c, gdbarch.h: Rebuild. * gdbarch.sh (bits_big_endian): Remove. * gdbtypes.h (union field_location): Update comment. * target-descriptions.c (make_gdb_type): Update. * valarith.c (value_bit_index): Update. * value.c (struct value) <bitpos>: Update comment. (unpack_bits_as_long, modify_field): Update. * value.h (value_bitpos): Update comment. Change-Id: I379b5e0c408ec8742f7a6c6b721108e73ed1b018
generated by cgit v1.1 at 2025-02-07 12:46:33 +0000