aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2021-05-17gdb/fortran: test case modified to suit the clang behavior.Bhuvanendra Kumar N2-3/+14
As mentioned in the test case itself, depending on the fortran compiler used, class member names used in the print commands and also output of these print commands varies. Existing print commands and its output are suited for gfortran, hence they were failing with clang compiler and test case was modified accordingly for clang compiler. gdb/testsuite/ChangeLog: * gdb.base/class-allocatable-array.exp: Modified test for clang.
2021-05-16CTF: handle forward reference typeWeimin Pan5-27/+562
The problems can be illustrated, with any program, below: (gdb) print main $1 = {main} 0x0 The return type was incorrectly set in read_func_kind_type, with the name of the function, which leads c_type_print_base_1 to print it. In addition, the address of a new function needs to be set with that info in its minimal symtab entry, when the new function is added. After the fix: (gdb) print main $1 = {int ()} 0x4004b7 <main> A new test, gdb.ctf/funcreturn.exp, is added to the testsuite. gdb/ChangeLog: * ctfread.c (new_symbol): Set function address. (read_func_kind_type): Remove incorrect type name setting. Don't copy name returned from ctf_type_ame_raw throughout file. gdb/testsuite/ChangeLog: * gdb.ctf/funcreturn.exp: New file. * gdb.ctf/whatis.c: Copy from gdb.base.
2021-05-14Fix Python pretty-printing bug in RustTom Tromey6-2/+133
An upstream Rust bug notes notes that the Python pretty-printing feature is broken for values that appear as members of certain types in Rust. The bug here is that some of the Rust value-printing code calls value_print_inner, a method on rust_language. This bypasses the common code that calls into Python. I'm checking this in. gdb/ChangeLog 2021-05-14 Tom Tromey <tom@tromey.com> * rust-lang.c (rust_language::val_print_struct) (rust_language::print_enum): Use common_val_print, not value_print_inner. gdb/testsuite/ChangeLog 2021-05-14 Tom Tromey <tom@tromey.com> * gdb.rust/pp.exp: New file. * gdb.rust/pp.py: New file. * gdb.rust/pp.rs: New file.
2021-05-14testsuite: Cleanup some temp dirs with gdb-index filesBernd Edlinger3-0/+29
After the gdb test-suite runs there are some files left in /tmp/tmp*/*.gdb-index, remove those files and the directory at the end of the test case. gdb/testsuite: 2021-05-14 Bernd Edlinger <bernd.edlinger@hotmail.de> * gdb.base/index-cache.exp: Cleanup $cache_dir/*.gdb-index and remove the directory. * gdb.dwarf2/per-bfd-sharing.exp: Likewise.
2021-05-14gdb/python: add a 'connection_num' attribute to Inferior objectsTankut Baris Aktemur7-1/+70
Define a 'connection_num' attribute for Inferior objects. The read-only attribute is the ID of the connection of an inferior, as printed by "info inferiors". In GDB's internal terminology, that's the process stratum target of the inferior. If the inferior has no target connection, the attribute is None. gdb/ChangeLog: 2021-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * python/py-inferior.c (infpy_get_connection_num): New function. (inferior_object_getset): Add a new element for 'connection_num'. * NEWS: Mention the 'connection_num' attribute of Inferior objects. gdb/doc/ChangeLog: 2021-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * python.texi (Inferiors In Python): Mention the 'connection_num' attribute. gdb/testsuite/ChangeLog: 2021-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * gdb.python/py-inferior.exp: Add test cases for 'connection_num'.
2021-05-14gdb: some int to bool conversion in remote.cAndrew Burgess2-17/+21
Convert a couple of local variables from int to bool. There should be no user visible changes after this commit. gdb/ChangeLog: * remote.c (check_pending_events_prevent_wildcard_vcont): Change argument type, update and re-wrap, header comment. (remote_target::commit_resumed): Convert any_process_wildcard and may_global_wildcard_vcont from int to bool.
2021-05-14gdb: fix pretty printing max depth behaviourKent Cheung9-37/+77
The 'print max-depth' feature incorrectly causes GDB to skip printing the string representation of pretty printed variables if the variable is stored at a nested depth corresponding to the set max-depth value. This change ensures that it is always printed before checking whether the maximum print depth has been reached. Regression tested with GCC 7.3.0 on x86_64, ppc64le, aarch64. gdb/ChangeLog: * cp-valprint.c (cp_print_value): Replaced duplicate code. * guile/scm-pretty-print.c (ppscm_print_children): Check max_depth just before printing child values. (gdbscm_apply_val_pretty_printer): Don't check max_depth before printing string representation. * python/py-prettyprint.c (print_children): Check max_depth just before printing child values. (gdbpy_apply_val_pretty_printer): Don't check max_depth before printing string representation. gdb/testsuite/ChangeLog: * gdb.python/py-format-string.c: Added a variable to test. * gdb.python/py-format-string.exp: Check string representation is printed at appropriate max_depth settings. * gdb.python/py-nested-maps.exp: Likewise. * gdb.guile/scm-pretty-print.exp: Add additional tests.
2021-05-14sim: create header namespaceMike Frysinger2-2/+7
The gdb/callback.h & gdb/remote-sim.h headers have nothing to do with gdb and are really definitions for the libsim API under the sim/ tree. While gdb uses those headers as a client, it's not specific to it. So create a new sim/ namespace and move the headers there.
2021-05-14gdb: lm32: drop unused sim headersMike Frysinger2-3/+5
Looks like these were copied & pasted as nothing from them are used.
2021-05-13gdb: maybe unpush target from old inferior in inf_child_target::follow_execSimon Marchi4-1/+39
I realized that with "follow-exec-mode == new", the process target stayed pushed in the original inferior. This can cause a small incoherence: $ ./gdb -q -nx --data-directory=data-directory -ex "set follow-exec-mode new" --args execer args-for-execer Reading symbols from execer... (gdb) r Starting program: /home/smarchi/build/binutils-gdb/gdb/execer args-for-execer I am execer and my argv[1] is: args-for-execer process 3562426 is executing new program: /home/smarchi/build/binutils-gdb/gdb/execee [New inferior 2] [New process 3562426] I am execee and my argv[1] is: arg-for-execee [Inferior 2 (process 3562426) exited normally] (gdb) info inferiors Num Description Connection Executable 1 <null> 1 (native) /home/smarchi/build/binutils-gdb/gdb/execer * 2 <null> /home/smarchi/build/binutils-gdb/gdb/execee (gdb) maintenance print target-stack The current target stack is: - exec (Local exec file) - None (None) (gdb) inferior 1 [Switching to inferior 1 [<null>] (/home/smarchi/build/binutils-gdb/gdb/execer)] (gdb) maintenance print target-stack The current target stack is: - native (Native process) - exec (Local exec file) - None (None) On exec, when execution continues into inferior 2, the native target isn't unpushed from inferior 1. When inferior 2's execution finishes normally, inf_child_target::mourn_inferior unpushes the native target, because the native target has been implicitly opened. I think that if the native target was implicitly opened, it should be unpushed from inferior 1, just like it is unpushed from an inferior whose execution terminate. This patch implements that. gdb/ChangeLog: * inf-child.h (inf_child_target) <follow_exec>: New. * inf-child.c (inf_child_target::follow_exec): New. Change-Id: I782cc08d73d93a990f4e53611107f68b2cb58af1
2021-05-13gdb: on exec, delegate pushing / unpushing target and adding thread to ↵Simon Marchi9-47/+107
target_ops::follow_exec On "exec", some targets need to unpush themselves from the inferior, and do some bookkeeping, like forgetting the data associated to the exec'ing inferior. One such example is the thread-db target. It does so in a special case in thread_db_target::wait, just before returning the TARGET_WAITKIND_EXECD event to its caller. We have another such case in the context of rocm-gdb [1], where the "rocm" target is pushed on top of the linux-nat target. When an exec happens, we want to unpush the rocm target from the exec'ing inferior to close some file descriptors that refer to the pre-exec address space and forget about that inferior. We then want to push the target on the inferior in which execution continues, to open the file descriptors for the post-exec address space. I think that a good way to address this cleanly is to do all this in the target_ops::follow_exec implementations. Make the process_stratum_target::follow_exec implementation have the default behavior of pushing itself to the new inferior's target stack (if execution continues in a new inferior) and add the initial thread. remote_target::follow_exec is an example of process target that wants to do a bit more than the default behavior. So it calls process_stratum_target::follow_exec first and does the extra work second. linux-thread-db (a non-process target) implements follow_exec to do some bookeeping (forget about that process' data), before handing down the event down to the process target (which hits process_stratum_target::follow_exec). gdb/ChangeLog: * target.h (struct target_ops) <follow_exec>: Add ptid_t parameter. (target_follow_exec): Likewise. * target.c (target_follow_exec): Add ptid_t parameter. * infrun.c (follow_exec): Adjust call to target_follow_exec, don't push target nor create thread. * linux-thread-db.c (class thread_db_target) <follow_exec>: New. (thread_db_target::wait): Just return on TARGET_WAITKIND_EXECD. (thread_db_target::follow_exec): New. * remote.c (class remote_target) <follow_exec>: Add ptid_t parameter. (remote_target::follow_exec): Call process_stratum_target::follow_exec. * target-delegates.c: Re-generate. Change-Id: I3f96d0ba3ea0dde6540b7e1b4d5cdb01635088c8
2021-05-13gdb: call target_follow_exec when "set follow-exec-mode" is "same"Simon Marchi3-2/+12
target_follow_exec is currently only called in the "follow-exec-mode == new" branch of follow_exec, not the "follow-exec-mode == same" branch. I think it would make sense to call it regardless of the mode to let targets do some necessary handling. This is needed in the context of rocm-gdb [1], where a target is pushed on top of the linux-nat target. On exec, it needs to do some bookkeeping, close some file descriptors / handles that were related to the process pre-exec and open some new ones for the process post-exec. However, by looking at the only in-tree implementation of target_ops::follow_exec, remote_target::follow_exec, I found that it would be useful for the extended-remote target too, to align its behavior with native debugging (although I think that behavior is not very user-friendly, see PR 27745 [2]). Using two programs, one (let's call it "execer") that execs the other (let's call it "execee"), with native: $ ./gdb -q -nx --data-directory=data-directory ./execer Reading symbols from ./execer... (gdb) r Starting program: /home/simark/build/binutils-gdb/gdb/execer I am execer process 1495622 is executing new program: /home/simark/build/binutils-gdb/gdb/execee I am execee [Inferior 1 (process 1495622) exited normally] (gdb) r Starting program: /home/simark/build/binutils-gdb/gdb/execee I am execee [Inferior 1 (process 1495626) exited normally] And now with gdbserver (some irrelevant output lines removed for brevity): $ ./gdbserver --once --multi :1234 ... $ ./gdb -q -nx --data-directory=data-directory ./execer -ex "set remote exec-file /home/simark/build/binutils-gdb/gdb/execer" -ex "tar ext :1234" Reading symbols from ./execer... Remote debugging using :1234 (gdb) r Starting program: /home/simark/build/binutils-gdb/gdb/execer process 1495724 is executing new program: /home/simark/build/binutils-gdb/gdb/execee [Inferior 1 (process 1495724) exited normally] (gdb) r `target:/home/simark/build/binutils-gdb/gdb/execee' has disappeared; keeping its symbols. Starting program: target:/home/simark/build/binutils-gdb/gdb/execee warning: Build ID mismatch between current exec-file target:/home/simark/build/binutils-gdb/gdb/execee and automatically determined exec-file target:/home/simark/build/binutils-gdb/gdb/execer exec-file-mismatch handling is currently "ask" Reading /home/simark/build/binutils-gdb/gdb/execer from remote target... Load new symbol table from "target:/home/simark/build/binutils-gdb/gdb/execer"? (y or n) When handling the exec, GDB updates the exec-file of the inferior to be the execee. This means that a subsequent "run" will run the execee, not the original executable (execer). remote_target::follow_exec is meant to update the "remote exec-file", which is the file on the remote system that will be executed if you "run" the inferior, to the execee as well. However, this is not called when follow-exec-mode is same, because target_follow_exec is not called in this branch. As a result, GDB thinks the inferior is executing execee but the remote side is really executing execer, hence the mismatch message. By calling target_follow_exec in the "same" branch of the follow_exec function, we ensure that everybody agrees, and we get the same behavior with the extended-remote target as we get with the native target, the execee is executed on the second run: $ ./gdbserver --once --multi :1234 ... $ ./gdb -q -nx --data-directory=data-directory ./execer -ex "set remote exec-file /home/simark/build/binutils-gdb/gdb/execer" -ex "tar ext :1234" Reading symbols from ./execer... Remote debugging using :1234 (gdb) r Starting program: /home/simark/build/binutils-gdb/gdb/execer process 1501445 is executing new program: /home/simark/build/binutils-gdb/gdb/execee [Inferior 1 (process 1501445) exited normally] (gdb) r `target:/home/simark/build/binutils-gdb/gdb/execee' has disappeared; keeping its symbols. Starting program: target:/home/simark/build/binutils-gdb/gdb/execee [Inferior 1 (process 1501447) exited normally] (gdb) This scenario is tested in gdb.base/foll-exec-mode.exp, and in fact this patch fixes the test for me when using --target_board=native-extended-gdbserver. gdb/ChangeLog: * infrun.c (follow_exec): Call target_follow_fork when follow-exec-mode is same. * target.h (target_follow_fork): Improve doc. [1] https://github.com/ROCm-Developer-Tools/ROCgdb [2] https://sourceware.org/bugzilla/show_bug.cgi?id=27745 Change-Id: I4ee84a875e39bf3f8eaf3e6789a4bfe23a2a430e
2021-05-13gdb/testsuite: fix dates in last 3 ChangeLog entriesAndrew Burgess1-3/+3
Incorrect dates in last 3 ChangeLog entries for gdb/testsuite/ChangeLog.
2021-05-13gdb/testsuite: resolve remaining duplicate tests in gdb.guile/Andrew Burgess2-76/+86
The remaining duplicates are resolved by adding a with_test_prefix and reindenting a proc. I also added a couple of additional test names to some of the tests. gdb/testsuite/ChangeLog: * gdb.guile/scm-pretty-print.exp (run_lang_tests): Give some tests unique names, also wrap proc body in with_test_prefix.
2021-05-13gdb/testsuite: resolve duplicate test names in gdb.guile/*.expAndrew Burgess6-45/+69
This commit resolves almost all of the remaining duplicate test names in gdb.guile/*.exp. This is done by either: - Making use of with_test_prefix, - Giving tests a unique name, - Extending the existing name to make it unique, - Not printing PASS lines for simple setup commands (e.g. loading support modules, or adjusting GDB internal settings not relating to guile). gdb/testsuite/ChangeLog: * gdb.guile/scm-frame-args.exp: Add with_test_prefix to resolve duplicate test names. * gdb.guile/scm-parameter.exp: Provide test names to avoid duplicate names based on the command being run. * gdb.guile/scm-symbol.exp: Extend test name to make it unique. * gdb.guile/scm-type.exp (restart_gdb): Don't print PASS line when loading a support module. (test_equality): Update test name to match the actual test, making the name unique in the process. * gdb.guile/scm-value.exp (test_value_in_inferior): Add test names to resolve duplicate tests. (test_inferior_function_call): Likewise. (test_subscript_regression): Likewise.
2021-05-13gdb/testsuite: remove some duplicate test names from guile testsAndrew Burgess2-3/+18
The guile support library has some "tests" that are actually being used to setup GDB ready for the real guile tests, e.g. we load some support modules, and define some helper functions. As this setup is done every time we call gdb_guile_runto_main, which could be called multiple times in a single test script, this can lead to duplicate PASS lines. As this setup is all pretty basic, and isn't the actual focus of the real tests, then in this commit I pass an empty test name through to the gdb_test_no_output calls, the result of this is that the PASS lines are no longer printed. This removes some duplicate tests from the gdb.guile/*.exp set of tests. gdb/testsuite/ChangeLog: * lib/guile.exp (gdb_scm_load_file): Use empty test name to silence PASS lines. (gdb_install_guile_module): Likewise.
2021-05-13gdb: remove cmd_list_element::pre_show_hookSimon Marchi3-8/+6
This is unused, remove it. gdb/ChangeLog: * cli/cli-decode.h (struct cmd_list_element) <pre_show_hook>: Remove. * cli/cli-setshow.c (do_show_command): Adjust. Change-Id: Ib9cd79d842550392b062309e1e5c079ad5d7571a
2021-05-13[AArch64] Fix off-by-one when calculating tag granules.Luis Machado2-2/+8
When we want to fetch tags from a memory range, the last address in that range is not included. There is a off-by-one error in aarch64_mte_get_tag_granules, which this patch fixes. gdb/ChangeLog: 2021-05-13 Luis Machado <luis.machado@linaro.org> * arch/aarch64-mte-linux.c (aarch64_mte_get_tag_granules): Don't include the last address in the range.
2021-05-12gdb: make gdbpy_parse_command_name return a unique_xmalloc_ptrSimon Marchi4-54/+61
This avoids some manual memory management. cmdpy_init correctly transfers ownership of the name to the cmd_list_element, as it sets the name_allocated flag. However, cmdpy_init (and add_setshow_generic) doesn't, it looks like the name is just leaked. This is a bit tricky, because it actually creates two commands (one set and one show), it would take a bit of refactoring of the command code to give each their own allocated copy. For now, just keep doing what the current code does but in a more explicit fashion, with an explicit release. gdb/ChangeLog: * python/python-internal.h (gdbpy_parse_command_name): Return gdb::unique_xmalloc_ptr. * python/py-cmd.c (gdbpy_parse_command_name): Likewise. (cmdpy_init): Adjust. * python/py-param.c (parmpy_init): Adjust. (add_setshow_generic): Take gdb::unique_xmalloc_ptr, release it when done. Change-Id: Iae5bc21fe2b22f12d5f954057b0aca7ca4cd3f0d
2021-05-12Revert "[gdb/symtab] Fix infinite recursion in dwarf2_cu::get_builder()"Tom de Vries4-18/+25
This reverts commit 4cf88725da1cb503be04d3237354105ec170bc86. It causes the following regression: ... $ cat shadow.cc namespace A {} int main() { using namespace A; return 0; } $ g++-10 -g shadow.cc -flto -o shadow $ ./gdb -q -batch ./shadow -ex "b main" Aborted (core dumped) ...
2021-05-12Guile: add value-const-valueGeorge Barrett7-2/+51
The Guile API doesn't currently have an equivalent to the Python API's gdb.Value.const_value(). This commit adds a procedure with equivalent semantics to the Guile API. gdb/ChangeLog: * NEWS (Guile API): Note the addition of the new procedure. * guile/scm-value.c (gdbscm_value_const_value): Add implementation of value-const-value procedure. (value_functions): Add value-const-value procedure. gdb/doc/ChangeLog: * guile.texi (Values From Inferior In Guile): Add documentation for value-const-value. gdb/testsuite/ChangeLog: * gdb.guile/scm-value.exp (test_value_in_inferior): Add test for value-const-value.
2021-05-12Guile: add value-{rvalue-,}reference-valueGeorge Barrett7-0/+88
The Guile API doesn't currently have an equivalent to the Python API's Value.reference_value() or Value.rvalue_reference_value(). This commit adds a procedure with equivalent semantics to the Guile API. gdb/ChangeLog: * NEWS (Guile API): Note the addition of new procedures. * guile/scm-value.c (gdbscm_reference_value): Add helper function for reference value creation. (gdbscm_value_reference_value): Add implementation of value-reference-value procedure. (gdbscm_value_rvalue_reference_value): Add implementation of value-rvalue-reference-value procedure. (value_functions): Add value-reference-value procedure. Add value-rvalue-reference-value procedure. gdb/doc/ChangeLog: * guile.texi (Values From Inferior In Guile): Add documentation for value-reference-value. Add documentation for value-rvalue-reference-value. gdb/testsuite/ChangeLog: * gdb.guile/scm-value.exp (test_value_in_inferior): Add test for value-reference-value. Add test for value-rvalue-reference-value.
2021-05-12Guile: improved rvalue reference supportGeorge Barrett6-0/+25
Adds a couple of missing bits to the Guile API to make C++11 rvalue reference values and types usable from Guile scripts. gdb/ChangeLog: * guile/scm-type.c (type_integer_constants): Add binding for TYPE_CODE_RVALUE_REF. * guile/scm-value.c (gdbscm_value_referenced_value): Handle dereferencing of rvalue references. * NEWS (Guile API): Note improvements in rvalue reference support. gdb/doc/ChangeLog: * guile.texi (Types In Guile): Add documentation for TYPE_CODE_RVALUE_REF.
2021-05-12gdb: generate the prefix name for prefix commands on demandMarco Barisione69-285/+236
Previously, the prefixname field of struct cmd_list_element was manually set for prefix commands. This seems verbose and error prone as it required every single call to functions adding prefix commands to specify the prefix name while the same information can be easily generated. Historically, this was not possible as the prefix field was null for many commands, but this was fixed in commit 3f4d92ebdf7f848b5ccc9e8d8e8514c64fde1183 by Philippe Waroquiers, so we can rely on the prefix field being set when generating the prefix name. This commit also fixes a use after free in this scenario: * A command gets created via Python (using the gdb.Command class). The prefix name member is dynamically allocated. * An alias to the new command is created. The alias's prefixname is set to point to the prefixname for the original command with a direct assignment. * A new command with the same name as the Python command is created. * The object for the original Python command gets freed and its prefixname gets freed as well. * The alias is updated to point to the new command, but its prefixname is not updated so it keeps pointing to the freed one. gdb/ChangeLog: * command.h (add_prefix_cmd): Remove the prefixname argument as it can now be generated automatically. Update all callers. (add_basic_prefix_cmd): Ditto. (add_show_prefix_cmd): Ditto. (add_prefix_cmd_suppress_notification): Ditto. (add_abbrev_prefix_cmd): Ditto. * cli/cli-decode.c (add_prefix_cmd): Ditto. (add_basic_prefix_cmd): Ditto. (add_show_prefix_cmd): Ditto. (add_prefix_cmd_suppress_notification): Ditto. (add_prefix_cmd_suppress_notification): Ditto. (add_abbrev_prefix_cmd): Ditto. * cli/cli-decode.h (struct cmd_list_element): Replace the prefixname member variable with a method which generates the prefix name at runtime. Update all code reading the prefix name to use the method, and remove all code setting it. * python/py-cmd.c (cmdpy_destroyer): Remove code to free the prefixname member as it's now a method. (cmdpy_function): Determine if the command is a prefix by looking at prefixlist, not prefixname.
2021-05-12gdb, btrace, pt: ignore status update enable eventsMarkus Metzger2-0/+8
Future versions of libipt report enable/disable status updates on PSB+. Ignore them.
2021-05-11gdb: fix indentation in arm_record_data_proc_misc_ld_strSimon Marchi2-14/+19
The scopes under this "if" are over-indented, fix that. gdb/ChangeLog: * arm-tdep.c (arm_record_data_proc_misc_ld_str): Fix indentation. Change-Id: I84a551793207ca95d0bc4f122e336555c8179c0e
2021-05-11gdb: fix indentation of cmd_list_elementSimon Marchi2-193/+197
This structure declaration is over-indented, fix that. gdb/ChangeLog: * cli/cli-decode.h (struct cmd_list_element): Fix indentation. Change-Id: I17c9cd739a233239b3add72f4fce7947c20907cd
2021-05-11[gdb/testsuite] Update infrun regexp in gdb.base/watch_thread_num.expTom de Vries2-4/+21
The test-case gdb.base/watch_thread_num.exp contains an infrun regexp: ... -re "infrun:" { ... which doesn't trigger because: - the test-case doesn't contain "set debug infrun 1", and - if we hack the test-case to add this, the regexp doesn't match because "[infrun] " is printed instead. Make the test pass with "set debug infrun 1" and add the setting commented out. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2021-05-11 Tom de Vries <tdevries@suse.de> * gdb.base/watch_thread_num.exp: Fix "set debug infrun 1" FAILs. Add "set debug infrun 1" commented out.
2021-05-11[gdb/testsuite] Fix read1 timeout in gdb.base/gdb-sigterm.expTom de Vries2-1/+5
When running check-read1, I run into a timeout in test-case gdb.base/gdb-sigterm.exp: ... [infrun] handle_inferior_event: status->kind = stopped, \ signal = GDB_SIGNAL_TRAP^M [infrun] start_step_over: enter^M [infrun] start_step_overFAIL: gdb.base/gdb-sigterm.exp: \ expect eof #0 (timeout) gdb.base/gdb-sigterm.exp: expect eof #0: stepped 0 times FAIL: gdb.base/gdb-sigterm.exp: 50 SIGTERM passes ... The corresponding gdb_test_multiple has an exp_continue clause, but it doesn't trigger because the regexp greps for 'infrun: ' instead of '[infrun] '. Fix the timeout by fixing the infrun regexp. Tested on x86_64-linux, with check and check-read1. gdb/testsuite/ChangeLog: 2021-05-11 Tom de Vries <tdevries@suse.de> * gdb.base/gdb-sigterm.exp: Fix exp_continue regexp.
2021-05-11gdb/fortran: Breakpoint location is modified.Bhuvanendra Kumar N2-2/+6
Breakpoint location is modified to "return" statement which is outside the DO loop. Because the label 100 of DO loop should get executed for each iteration as shared in this external link: http://www-pnp.physics.ox.ac.uk/~gronbech/intfor/node18.html. flang compiler is following this fortran standard, whereas gfortran compiler is not following, hence the test case is passing with gfortran and failing with flang. but to correct this gfortran behavior, bug has been filed in bugzilla (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99816). As reported in the bug, with gfortran, label 100 of DO loop is reached only after the completion of the entire DO loop. Hence at label 100, all the array elements are set and printing of array element a(2) succeeds. whereas with flang, when we are at label 100 for first time, array element a(2) is not yet set, only a(1) is set, hence moving the breakpoint location to outside the DO loop, so that once we are outside the DO loop, we can print any of the array elements. This change in test case is done irrespective of any fortran compiler. gdb/testsuite/ChangeLog: * gdb.fortran/array-element.exp: Breakpoint location is modified.
2021-05-10[PR gdb/27614] gdb-add-index fails on symlinks.Lancelot SIX4-0/+86
PR 27614 shows that gdb-add-index fails to generate the index when its argument is a symlink. The following one liner illustrates the reported problem: $ echo 'int main(){}'|gcc -g -x c -;ln -s a.out symlink;gdb-add-index symlink gdb-add-index: No index was created for symlink gdb-add-index: [Was there no debuginfo? Was there already an index?] $ ls -l -rwxr-xr-x 1 25712 Mar 19 23:05 a.out* -rw------- 1 8277 Mar 19 23:05 a.out.gdb-index lrwxrwxrwx 1 5 Mar 19 23:05 symlink -> a.out* GDB generates the .gdb-index file with a name that matches the name of the actual program (a.out.gdb-index here), not the symlink that references it. The remaining of the script is looking for a file named after the provided argument (would be 'symlink.gdb-index' in our example). gdb/ChangeLog: PR gdb/27614 * contrib/gdb-add-index.sh: Fix when called with a symlink as an argument. gdb/testsuite/ChangeLog: PR gdb/27614 * gdb.dwarf2/gdb-add-index-symlink.exp: New test.
2021-05-10gdb/testsuite: don't use source tree as temporary HOME directoryAndrew Burgess2-1/+17
In this commit: commit 1845e254645efbc02248345ccdb557d265dd8ae1 Date: Wed May 5 16:50:17 2021 +0100 gdb/guile: perform tilde expansion when sourcing guile scripts A test was added that tries to source a guile script from the users HOME directory. In order to achieve this the test (temporarily) modifies $HOME to point into the binutils-gdb source tree. The problem with this is that sourcing a guile script can cause the guile script to be byte compiled and written into a .cache/ directory, which is stored .... in the $HOME directory. The result was that the test added in the above commit would cause a .cache/ directory to be added into the binutils-gdb source tree. In this commit the test is updated to create a new directory in the build tree, the file we want to source is copied over, and $HOME is set to point at the location in the build tree. Now when the test is run the .cache/ directory is created in the build tree, leaving the source tree untouched. gdb/testsuite/ChangeLog: * gdb.guile/guile.exp: Don't use the source directory as a temporary HOME directory.
2021-05-10gdb/testsuite: use proc parameters in gdb.arch/amd64-osabi.expSimon Marchi2-3/+8
This test has a little oversight: the test procedure doesn't actually use its parameters, the commands and expected patterns are hard-coded, so we always test with i386:x86-64, instead of with the three arches. Fix that. gdb/testsuite/ChangeLog: * gdb.arch/amd64-osabi.exp (test_osabi_none): Use the parameters. Change-Id: Iee2c32963d09e502ae791d5df2b6c04a1f49a57a
2021-05-10gdb, gdbserver: make status_to_str display the signal nameSimon Marchi2-4/+10
I was looking at some "set debug lin-lwp" logs, and saw that a thread received the "Child exited" signal. It took me a moment to realize that this was SIGCHLD. I then thought that it would be nice for status_to_str to show the signal name (SIGCHLD) in addition to the description "Child exited", since people are much more used to referring to signals using their names. Fortunately, libiberty contains a handy function to get the signal name from the signal number, strsigno, use that. The output of "set debug lin-lwp" now looks like: [linux-nat] linux_nat_wait_1: waitpid 1209631 received SIGTRAP - Trace/breakpoint trap (stopped) gdb/ChangeLog: * nat/linux-waitpid.c (status_to_str): Show signal name. Change-Id: I8ad9b1e744dd64461fd87b08d5c29f9ef97c4691
2021-05-10gdb/doc: reword a sentenceAndrew Burgess3-2/+7
Change this: The available watchpoint types represented by constants are defined in the gdb module: to this: The available watchpoint types are represented by constants defined in the gdb module: The new version matches a similar line a few lines up the document which reads: The available types are represented by constants defined in the gdb module: gdb/doc/ChangeLog: * guile.texinfo (Breakpoints In Guile): Reword sentence. * python.texinfo (Breakpoints In Python): Reword sentence.
2021-05-09gdb/doc: document 'set debug py-unwind'Andrew Burgess2-0/+12
When the 'set debug py-unwind' flag was added, it was never documented in the manual. This commit adds some text for this command to the manual. gdb/doc/ChangeLog: * python.texinfo (Python Commands): Document 'set debug py-unwind' and 'show debug py-unwind'.
2021-05-09gdb/py: add some debugging to py-breakpoint.cAndrew Burgess4-3/+83
Adds some new debugging to python/py-breakpoint.c. gdb/ChangeLog: * python/py-breakpoint.c (pybp_debug): New static global. (show_pybp_debug): New function. (pybp_debug_printf): Define. (PYBP_SCOPED_DEBUG_ENTER_EXIT): Define. (gdbpy_breakpoint_created): Add some debugging. (gdbpy_breakpoint_deleted): Likewise. (gdbpy_breakpoint_modified): Likewise. (_initialize_py_breakpoint): New function. gdb/doc/ChangeLog: * python.texinfo (Python Commands): Document 'set debug py-breakpoint' and 'show debug py-breakpoint'.
2021-05-09gdb/py: convert debug logging in py-unwind to use new schemeAndrew Burgess2-16/+51
Converts the debug print out in python/py-unwind.c to use the new debug printing scheme. I have also modified what is printed in a few places, for example, rather than printing frame pointers, I now print the frame level, this matches what we do in the general 'set debug frame' tracing, and is usually more helpful (I think). I also added a couple of ENTER/EXIT scope printers. gdb/ChangeLog: * python/py-unwind.c (pyuw_debug): Convert to bool. (show_pyuw_debug): New function. (pyuw_debug_printf): Define. (PYUW_SCOPED_DEBUG_ENTER_EXIT): Define. (pyuw_this_id): Convert to new debug print macros. (pyuw_prev_register): Likewise. (pyuw_sniffer): Likewise. (pyuw_dealloc_cache): Likewise. (_initialize_py_unwind): Update now pyuw_debug is a bool, and add show function when registering.
2021-05-09gdb: replace fprint_frame_idAndrew Burgess7-75/+68
Replace fprint_frame_id with a member function frame_id::to_string that returns a std::string. Convert all of the previous users of fprint_frame_id to use the new member function. This means that instead of writing things like this: fprintf_unfiltered (file, " id="); fprint_frame_id (file, s->id.id); We can write this: fprintf_unfiltered (file, " id=%s", s->id.id.to_string ().c_str ()); There should be no user visible changes after this commit. gdb/ChangeLog: * dummy-frame.c (fprint_dummy_frames): Convert use of fprint_frame_id to use frame_id::to_string. * frame.c (fprint_field): Delete. (fprint_frame_id): Moved to... (frame_id::to_string): ...this, rewritten to return a string. (fprint_frame): Convert use of fprint_frame_id to use frame_id::to_string. (compute_frame_id): Likewise. (frame_id_p): Likewise. (frame_id_eq): Likewise. (frame_id_inner): Likewise. * frame.h (struct frame_id) <to_string>: New member function. (fprint_frame_id): Delete declaration. * guile/scm-frame.c (frscm_print_frame_smob): Convert use of fprint_frame_id to use frame_id::to_string. * python/py-frame.c (frame_object_to_frame_info): Likewise. * python/py-unwind.c (unwind_infopy_str): Likewise. (pyuw_this_id): Likewise.
2021-05-08gdb, gdbserver: make status_to_str return std::stringSimon Marchi4-24/+35
Instead of using a static buffer. This is safer, and we don't really mind about any extra dynamic allocation here, since it's only used for debug purposes. gdb/ChangeLog: * nat/linux-waitpid.c (status_to_str): Return std::string. * nat/linux-waitpid.h (status_to_str): Likewise. * linux-nat.c (linux_nat_post_attach_wait): Adjust. (linux_nat_target::attach): Adjust. (linux_handle_extended_wait): Adjust. (wait_lwp): Adjust. (stop_wait_callback): Adjust. (linux_nat_filter_event): Adjust. (linux_nat_wait_1): Adjust. * nat/linux-waitpid.c (status_to_str): Adjust. * nat/linux-waitpid.h (status_to_str): Adjust. gdbserver/ChangeLog: * linux-low.cc (linux_process_target::wait_for_event_filtered): Adjust to status_to_str returning std::string. Change-Id: Ia8aead70270438a5690f243e6faafff6c38ff757
2021-05-08gdb: add missing space in infrun_debug_printfSimon Marchi2-1/+5
gdb/ChangeLog: * infrun.h (infrun_debug_printf): Add missing space. Change-Id: I476096a098451ff2019ab38caa41ebfef0e04a1c
2021-05-08Don't run personality syscall at configure time; don't check it at allPedro Alves5-96/+11
Currently, in order to tell whether support for disabling address space randomization on Linux is available, GDB checks if the personality syscall works, at configure time. I.e., it does a run test, instead of a compile/link test: AC_RUN_IFELSE([PERSONALITY_TEST], [have_personality=true], [have_personality=false], This is a bit bogus, because the machine the build is done on may not (and is when you consider distro gdbs) be the machine that eventually runs gdb. It would be better if this were a compile/link test instead, and then at runtime, GDB coped with the personality syscall failing. Actually, GDB already copes. One environment where this is problematic is building GDB in a Docker container -- by default, Docker runs the container with seccomp, with a profile that disables the personality syscall. You can tell Docker to use a less restricted seccomp profile, but I think we should just fix it in GDB. "man 2 personality" says: This system call first appeared in Linux 1.1.20 (and thus first in a stable kernel release with Linux 1.2.0); library support was added in glibc 2.3. ... ADDR_NO_RANDOMIZE (since Linux 2.6.12) With this flag set, disable address-space-layout randomization. glibc 2.3 was released in 2002. Linux 2.6.12 was released in 2005. The original patch that added the configure checks was submitted in 2008. The first version of the patch that was submitted to the list called personality from common code: https://sourceware.org/pipermail/gdb-patches/2008-June/058204.html and then was moved to Linux-specific code: https://sourceware.org/pipermail/gdb-patches/2008-June/058209.html Since HAVE_PERSONALITY is only checked in Linux code, and ADDR_NO_RANDOMIZE exists for over 15 years, I propose just completely removing the configure checks. If for some odd reason, some remotely modern system still needs a configure check, then we can revert this commit but drop the AC_RUN_IFELSE in favor of always doing the AC_LINK_IFELSE cross-compile fallback. gdb/ChangeLog: * linux-nat.c (linux_nat_target::supports_disable_randomization): Remove references to HAVE_PERSONALITY. * nat/linux-personality.c: Remove references to HAVE_PERSONALITY. (maybe_disable_address_space_randomization) (~maybe_disable_address_space_randomizatio): Remove references to HAVE_PERSONALITY. * config.in, configure: Regenerate. gdbserver/ChangeLog: * linux-low.cc: (linux_process_target::supports_disable_randomization): Remove reference to HAVE_PERSONALITY. * config.in, configure: Regenerate. gdbsupport/ChangeLog: * common.m4 (personality test): Remove.
2021-05-07gdb/guile: perform tilde expansion when sourcing guile scriptsAndrew Burgess4-2/+28
Before this patch: (gdb) source ~/script.scm ERROR: In procedure apply-smob/1: ERROR: In procedure primitive-load-path: Unable to find file "~/script.scm" in load path Error while executing Scheme code. (gdb) This is because the path is not tilde expanded. In contrast, when sourcing a .py or .gdb script the path is tilde expanded. This commit fixes this oversight, and allows the above source command to work as expected. The tilde expansion is done in the generic GDB code before we call the sourcer function for any particular extension language. gdb/ChangeLog: * cli/cli-cmds.c: Add 'gdbsupport/gdb_tilde_expand.h' include. (source_script_with_search): Perform tilde expansion. gdb/testsuite/ChangeLog: * gdb.guile/guile.exp: Add an extra test.
2021-05-07gdb/testsuite: use gdb_test_no_output instead of send_gdbAndrew Burgess2-2/+7
I noticed gdb.base/ptype-offsets.exp failing occasionally, this was due to lines like this in the test script: send_gdb "set print type hex on\n" As this does not match the '(gdb)' prompt that is produced, the prompt would sometimes be matched against the next test, causing the next test to think its output was missing and fail. Fix this by switching to: gdb_test_no_output "set print type hex on" gdb/testsuite/ChangeLog: * gdb.base/ptype-offsets.exp: Replace use of send_gdb with gdb_test_no_output.
2021-05-07gdb: make target_desc_info::filename an std::stringSimon Marchi2-20/+26
To make the management of memory automatic. As to why I chose to make this an std::string and not an std::unique_xmalloc_ptr<char>: some parts of the code consider both a NULL value and an empty string value to mean "no filename". target_desc_info_from_user_p, however, doesn't check for a non-NULL but empty string value. So it seems like having two ways of denoting "no filename" can lead to these kinds of inconsistencies. Using std::string, "no filename" is only represented by an empty value. As a bonus, using an std::string lets us copy target_desc_info objects using the default assignment operator. gdb/ChangeLog: * target-descriptions.c (struct target_desc_info) <filename>: Make std::string. (copy_inferior_target_desc_info): Adjust. (target_desc_info_free): Adjust. (target_find_description): Adjust. (set_tdesc_filename_cmd): Adjust. (show_tdesc_filename_cmd): Adjust. (unset_tdesc_filename_cmd): Adjust. (maint_print_c_tdesc_cmd): Adjust. Change-Id: I4e3a6ad8ccda2b88c202471d4f54249753cad127
2021-05-07gdb: (de-)allocate target_desc_info with new/deleteSimon Marchi2-5/+13
In preparation for using non-POD types in the struct. gdb/ChangeLog: * target-descriptions.c (struct target_desc_info): Initialize fields. (get_tdesc_info): Use new. (target_desc_info_free): Use delete. Change-Id: I10fdaeeae7cdbd7930ae7adeeb13f7f363c67c7a
2021-05-07gdb: change target_desc_info::fetched to boolSimon Marchi2-3/+10
gdb/ChangeLog: * target-descriptions.c (struct target_desc_info) <fetched>: bool. (target_find_description): Adjust. (target_clear_description): Adjust. Change-Id: Ib69e097b38cf270e674f1249105d535a312954e1
2021-05-07gdb: remove target description macrosSimon Marchi2-38/+53
In my opinion, the target_desc_fetched, current_target_desc and target_description_filename macros in target-descriptions.c are not very useful. I don't think it's useful to hide that they operate on the current inferior, as everything currently works under the assumption that the various tdesc commands operate on the current inferior, and I don't see that changing in the foreseeable future. This change also avoids having multiple unnecessary calls to current_inferior and get_tdesc_info per function. gdb/ChangeLog: * target-descriptions.c (struct target_desc_info) <tdesc>: Adjust doc. (target_desc_fetched): Remove. (current_target_desc): Remove. (target_description_filename): Remove. (target_find_description): Adjust. (target_clear_description): Adjust. (target_current_description): Adjust. (set_tdesc_filename_cmd): Adjust. (show_tdesc_filename_cmd): Adjust. (unset_tdesc_filename_cmd): Adjust. (maint_print_c_tdesc_cmd): Adjust. (maint_print_xml_tdesc_cmd): Adjust. Change-Id: Ibfb581490e949c16d59924e2cac633ede5c26c5b
2021-05-07gdb: some int to bool conversionAndrew Burgess4-7/+18
Change int parameter to bool in remote_notice_new_inferior (remote.c) and notice_new_inferior (infcmd.c), and update the callers. There should be no user visible changes after this commit. gdb/ChangeLog: * infcmd.c (notice_new_inferior): Change parameter type. * inferior.h (notice_new_inferior): Change parameter type. * remote.c (remote_notice_new_inferior): Change parameter type to bool. Also update type of local variable to bool. (remote_target::update_thread_list): Change type of local variable to bool. (remote_target::process_stop_reply): Pass bool instead of int to remote_notice_new_inferior.
2021-05-07gdb: remove reference to current inferior in target_stack::unpushSimon Marchi2-1/+6
target_stack::unpush needs to get the target beneath the target being unpushed to update the m_top field (which keeps the stratum of the top-most target). It currently does so using target_ops::beneath, which uses the target stack of the current inferior. The target stack of the current inferior is the same as the `this` in the unpush method. Avoid this detour and remove this reference to the current inferior by calling target_ops::find_beneath and passing `this` to find the target beneath `t` in the target stack that is `this`. gdb/ChangeLog: * target.c (target_stack::unpush): Call target_ops::find_beneath to get the target beneath `t`. Change-Id: If9d9661567c5c16f655d270bd2ec9f1b3aa6dadc