aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2020-05-25gdbsupport: Let construct_inferior_arguments take gdb::array_view paramMichael Weghorn1-2/+3
Adapt the construct_inferior_arguments function to take a gdb::array_view<char * const> parameter instead of a char * array and an int indicating the length and adapt the only call site. This will allow calling it more simply in a follow-up patch introducing more uses of the function. gdbsupport/ChangeLog: * common-inferior.cc, common-inferior.h (construct_inferior_arguments): Adapt to take a gdb::array_view<char * const> parameter. Adapt call site. Change-Id: I1c6496c8c0b0eb3ef3fda96e9e3bd64c5e6cac3c
2020-05-25gdbsupport: Adapt construct_inferior_argumentsMichael Weghorn1-6/+3
Allow construct_inferior_arguments to handle zero args and have it return a std::string, similar to how stringify_argv in gdbsupport/common-utils does. Also, add a const qualifier for the second parameter, since it is only read, not written to. The intention is to replace existing uses of stringify_argv by construct_inferior_arguments in a subsequent step, since construct_inferior_arguments properly handles special characters, while stringify_argv doesn't. gdbsupport/ChangeLog: * common-inferior.cc, common-inferior.h (construct_inferior_arguments): Adapt to handle zero args and return a std::string. Adapt call site. Change-Id: I126c4390a1018c7527b0b8fd545252ab8a5a7adc
2020-05-25gdb: Move construct_inferior_arguments to gdbsupportMichael Weghorn3-126/+5
This moves the function construct_inferior_arguments from gdb/inferior.h and gdb/infcmd.c to gdbsupport/common-inferior.{h,cc}. While at it, also move the function's comment to the header file to align with current standards. The intention is to use it from gdbserver in a follow-up commit. gdb/ChangeLog: * infcmd.c, inferior.h: (construct_inferior_arguments): Moved function from here to gdbsupport/common-inferior.{h,cc} gdbsupport/ChangeLog: * common-inferior.h, common-inferior.cc: (construct_inferior_arguments): Move function here from gdb/infcmd.c, gdb/inferior.h Change-Id: Ib9290464ce8c0872f605d8829f88352d064c30d6
2020-05-25[gdb/testsuite] Add comment in exec_is_pieTom de Vries2-0/+7
Add comment to exec_is_pie explaining why readelf -d output is not used. gdb/testsuite/ChangeLog: 2020-05-25 Tom de Vries <tdevries@suse.de> * lib/gdb.exp (exec_is_pie): Add comment.
2020-05-25[gdb/testsuite] Fix var use in compile_and_download_n_jit_soTom de Vries2-1/+6
In commit 1b59ca1cf1 "[gdb/testsuite] Fix tcl error in jit-elf-helpers.exp", I introduced a variable f in compile_and_download_n_jit_so, to be used in the untested message, but actually variable binfile was used instead: ... + set f [file tail $binfile] + untested "failed to compile shared library $binfile" ... Fix this by using $f in the untested message. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-05-25 Tom de Vries <tdevries@suse.de> * lib/jit-elf-helpers.exp (compile_and_download_n_jit_so): Use $f instead of $binfile in the untested message.
2020-05-25[gdb/testsuite] Fix exec_is_pie with gold linkerTom de Vries2-2/+8
When running test-case gdb.base/break-interp.exp with target board gold, we run into: ... gdb compile failed, pie failed to generate PIE executable ... The problem is that the proc exec_is_pie uses the PIE flag in the readelf -d output, which doesn't seem to be set by the gold linker. Instead, use the "Type" field in the readelf -h output. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-05-25 Tom de Vries <tdevries@suse.de> PR testsuite/26031 * lib/gdb.exp (exec_is_pie): Test readelf -h output.
2020-05-25[gdb/testsuite] Add target board goldTom de Vries2-0/+36
Add a target board that uses the gold linker. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-05-25 Tom de Vries <tdevries@suse.de> * boards/gold.exp: New file.
2020-05-24Revert "Add completion styling"Tom Tromey10-148/+32
This reverts commit eca1f90cf47a2edc1a1cd22e12c6c0f3b900654e. Several changes were requested, and it seemed simplest to revert it. gdb/ChangeLog 2020-05-23 Tom Tromey <tom@tromey.com> Revert commit eca1f90c: * NEWS: Remove entry for completion styling. * completer.c (_rl_completion_prefix_display_length): Move declaration later. (gdb_fnprint): Revert. (gdb_display_match_list_1): Likewise. * cli/cli-style.c (completion_prefix_style) (completion_difference_style, completion_suffix_style): Remove. (_initialize_cli_style): Revert. * cli/cli-style.h (completion_prefix_style) (completion_difference_style, completion_suffix_style): Don't declare. gdb/doc/ChangeLog 2020-05-23 Tom Tromey <tom@tromey.com> * gdb.texinfo (Output Styling): Don't mention completion styling. (Editing): Don't mention readline completion styling. gdb/testsuite/ChangeLog 2020-05-23 Tom Tromey <tom@tromey.com> * gdb.base/style.exp: Remove completion styling test. * lib/gdb-utils.exp (style): Remove completion styles.
2020-05-24gdb: make gdbarch.sh write gdbarch.{c,h} directlySimon Marchi3-55/+8
It was suggested in this thread [1] that gdbarch.sh should write to gdbarch.h and gdbarch.c directly. This patch implements that. When running gdbarch.sh, we currently need to move new-gdbarch.c over gdbarch.c and new-gdbarch.h over gdbarch.h. It might have been useful at some point to not have gdbarch.sh overwrite gdbarch.h and gdbarch.c, but with git it's really unnecessary. Any changes to gdbarch.sh can be inspected using `git diff`. A next step would be to have the Makefile automatically run gdbarch.sh if it sees that gdbarch.c and gdbarch.h are out of date. Or maybe even remove gdbarch.c and gdbarch.h from the tree and generate them in the build directory when building. But that requires more thinking and discussions, and I think that this change is already useful in itself. [1] https://sourceware.org/pipermail/gdb-patches/2020-May/168265.html gdb/ChangeLog; * gdbarch.sh: Write to gdbarch.c/gdbarch.h directly. Don't compare old and new versions. (compare_new): Remove. Change-Id: I7970a9e8af0afc0145cb5a28e73d94fbaa1e25b9
2020-05-24Don't remove C++ aliases from completions if symbol doesn't matchPedro Alves3-7/+19
completion_list_add_symbol currently tries to remove C++ function aliases from the completions match list even if the symbol passed down wasn't successfully added to the completion list because it didn't match. I.e., we call cp_canonicalize_string_no_typedefs for each and every C++ function in the program, which is useful work. This patch skips that useless work. gdb/ChangeLog: 2020-05-24 Pedro Alves <palves@redhat.com> * symtab.c (completion_list_add_name): Return boolean indication of whether the symbol matched. (completion_list_add_symbol): Don't try to remove C++ aliases if the symbol didn't match in the first place. * symtab.h (completion_list_add_name): Return bool.
2020-05-23gdb: remove TYPE_FIELD macroSimon Marchi31-81/+84
Replace all uses of it by type::field. Note that since type::field returns a reference to the field, some spots are used to assign the whole field structure. See ctfread.c, function attach_fields_to_type, for example. This is the same as was happening with the macro, so I don't think it's a problem, but if anybody sees a really nicer way to do this, now could be a good time to implement it. gdb/ChangeLog: * gdbtypes.h (TYPE_FIELD): Remove. Replace all uses with type::field.
2020-05-23Document the GDB 9.2 release in gdb/ChangeLogJoel Brobecker1-0/+4
gdb/ChangeLog: GDB 9.2 released.
2020-05-23Add completion stylingTom Tromey10-7/+172
Readline has a styling feature for completion -- if it is enabled, the common prefix of completions will be displayed in a different style. This doesn't work in gdb, because gdb implements its own completer. This patch implements the feature. However, it doesn't directly use the Readline feature, because gdb can do a bit better: it can let the user control the styling using the existing mechanisms. This version incorporates an Emacs idea, via Eli: style the prefix, the "difference character", and the suffix differently. gdb/ChangeLog 2020-05-23 Tom Tromey <tom@tromey.com> * NEWS: Add entry for completion styling. * completer.c (_rl_completion_prefix_display_length): Move declaration earlier. (gdb_fnprint): Use completion_style. (gdb_display_match_list_1): Likewise. * cli/cli-style.c (completion_prefix_style) (completion_difference_style, completion_suffix_style): New globals. (_initialize_cli_style): Register new globals. * cli/cli-style.h (completion_prefix_style) (completion_difference_style, completion_suffix_style): Declare. gdb/doc/ChangeLog 2020-05-23 Tom Tromey <tom@tromey.com> * gdb.texinfo (Output Styling): Mention completion styling. (Editing): Mention readline completion styling. gdb/testsuite/ChangeLog 2020-05-23 Tom Tromey <tom@tromey.com> * gdb.base/style.exp: Add completion styling test. * lib/gdb-utils.exp (style): Add completion styles.
2020-05-23Use safe-ctype.h (ISSPACE etc.) in symbol parsing & comparisonPedro Alves2-23/+38
This patch avoids depending on the current locale when parsing & comparing symbol names, by using libiberty's safe-ctype.h uppercase TOLOWER, ISXDIGIT, etc. macros instead of the standard ctype.h tolower, isxdigit, etc. macros/functions. This commit: commit b1b60145aedb8adcb0b9dcf43a5ae735c2f03b51 Author: Pedro Alves <palves@redhat.com> AuthorDate: Tue May 22 17:35:38 2018 +0100 Support UTF-8 identifiers in C/C++ expressions (PR gdb/22973) did something similar, except in the expression parser. This can improve GDB's symbol loading performance significantly. Currently strcmp_iw_ordered can show up high on profiles (called from sort_pst_symbols -> std::sort) because of the isspace and tolower functions. Hannes mentions seeing it as high as in ~24% of the profiling samples on Windows (https://sourceware.org/pipermail/gdb-patches/2020-May/168858.html). I tested GDB's performance (built with "-g -O2") loading a "-g -O0" build of gdb. I ran GDB 10 times like: /bin/time -f %e \ ./gdb/gdb --data-directory ./gdb/data-directory -nx \ -batch /tmp/gdb-g-O0 Then I computed the mean time. The baseline mean time was gdb 2.515 This patch brings the number down to gdb 2.096 Which is an around 16% improvement. gdb/ChangeLog: 2020-05-23 Pedro Alves <palves@redhat.com> * utils.c: Include "gdbsupport/gdb-safe-ctype.h". (parse_escape): Use ISDIGIT instead of isdigit. (puts_debug): Use gdb_isprint instead of isprint. (fprintf_symbol_filtered): Use ISALNUM instead of isalnum. (cp_skip_operator_token, skip_ws, strncmp_iw_with_mode): Use ISSPACE instead of isspace. (strncmp_iw_with_mode): Use TOLOWER instead of tolower and ISSPACE instead of isspace. (strcmp_iw_ordered): Use ISSPACE instead of isspace. (string_to_core_addr): Use TOLOWER instead of tolower, ISXDIGIT instead of isxdigit and ISDIGIT instead of isdigit. gdbsupport/ChangeLog: 2020-05-23 Pedro Alves <palves@redhat.com> * gdb-safe-ctype.h: New.
2020-05-22gdb: remove TYPE_FIELDS macroSimon Marchi12-32/+42
Remove all uses of the `TYPE_FIELDS` macro. Replace them with either: 1) type::fields, to obtain a pointer to the fields array (same as TYPE_FIELDS yields) 2) type::field, a new convenience method that obtains a reference to one of the type's field by index. It is meant to replace TYPE_FIELDS (type)[idx] with type->field (idx) gdb/ChangeLog: * gdbtypes.h (struct type) <field>: New method. (TYPE_FIELDS): Remove, replace all uses with either type::fields or type::field. Change-Id: I49fba10114417deb502060c6156aa5f7fc62462f
2020-05-22gdb: add type::fields / type::set_fieldsSimon Marchi14-86/+114
Add the `fields` and `set_fields` methods on `struct type`, in order to remove the `TYPE_FIELDS` macro. In this patch, the `TYPE_FIELDS` macro is changed to the `type::fields`, so all the call sites that use it to set the fields array are changed to use `type::set_fields`. The next patch will remove `TYPE_FIELDS` entirely. gdb/ChangeLog: * gdbtypes.h (struct type) <fields, set_fields>: New methods. (TYPE_FIELDS): Use type::fields. Change all call sites that modify the propery to use type::set_fields instead. Change-Id: I05174ce68f2ce3fccdf5d8b469ff141f14886b33
2020-05-22gdb: remove TYPE_NFIELDS macroSimon Marchi68-318/+322
Remove `TYPE_NFIELDS`, changing all the call sites to use `type::num_fields` directly. This is quite a big diff, but this was mostly done using sed and coccinelle. A few call sites were done by hand. gdb/ChangeLog: * gdbtypes.h (TYPE_NFIELDS): Remove. Change all cal sites to use type::num_fields instead. Change-Id: Ib73be4c36f9e770e0f729bac3b5257d7cb2f9591
2020-05-22gdb: add type::num_fields / type::set_num_fieldsSimon Marchi14-43/+62
Add the `num_fields` and `set_num_fields` methods on `struct type`, in order to remove the `TYPE_NFIELDS` macro. In this patch, the `TYPE_NFIELDS` macro is changed to use `type::num_fields`, so all the call sites that are used to set the number of fields are changed to use `type::set_num_fields`. The next patch will remove `TYPE_NFIELDS` completely. I think that in the future, we should consider making the interface of `struct type` better. For example, right now it's possible for the number of fields property and the actual number of fields set to be out of sync. However, I want to keep the existing behavior in this patch, just translate from macros to methods. gdb/ChangeLog: * gdbtypes.h (struct type) <num_fields, set_num_fields>: New methods. (TYPE_NFIELDS): Use type::num_fields. Change all call sites that modify the number of fields to use type::set_num_fields instead. Change-Id: I5ad9de5be4097feaf942d111077434bf91d13dc5
2020-05-22Remove obsolete declarationTom Tromey2-1/+5
Commit c9e0a7e3331 ("Remove munmap_listp_free_cleanup") removed munmap_listp_free, but missed a declaration. This patch removes that as well. gdb/ChangeLog 2020-05-22 Tom Tromey <tromey@adacore.com> * compile/compile-object-load.h (munmap_list_free): Don't declare.
2020-05-22gdb: Restore old annotations behaviour when printing frame infoAndrew Burgess9-20/+73
This undoes most of the changes from these commits: commit ec8e2b6d3051f0b4b2a8eee9917898e95046c62f Date: Fri Jun 14 23:43:00 2019 +0100 gdb: Don't allow annotations to influence what else GDB prints commit 0d3abd8cc936360f8c46502135edd2e646473438 Date: Wed Jun 12 22:34:26 2019 +0100 gdb: Remove an update of current_source_line and current_source_symtab as a result of the discussion here: https://sourceware.org/pipermail/gdb/2020-April/048468.html Having taken time to reflect on the discussion, and reading the documentation again I believe we should revert GDB's behaviour back to how it used to be. The original concern that triggered the initial patch was that when annotations were on the current source and line were updated (inside the annotation code), while when annotations are off this update would not occur. This was incorrect, as printing the source with the call to print_source_lines does also update the current source and line. Further, the documentation here: https://sourceware.org/gdb/current/onlinedocs/gdb/Source-Annotations.html#Source-Annotations Clearly states: "The following annotation is used instead of displaying source code: ^Z^Zsource filename:line:character:middle:addr ..." So it is documented that the 'source' annotation is a replacement for, and not in addition to, actually printing the source lie. There are still a few issues that I can see, these are: 1. In source.c:info_line_command, when annotations are on we call annotate_source_line, however, if annotations are off then there is no corresponding call to print the source line. This means that a if a user uses 'info line ...' with annotations on, and then does a 'list', they will get different results than if they had done this with annotations off. 2. It bothers me that the call to annotate_source_line returns a boolean, and that this controls a call to print_source_line (in stack.c:print_frame_info). The reason for this is that the source line annotation will only print something if the file is found, and the line number is in range for the file. It seems to me like an annotation should always be printed, either one that identifies the file and line, or one that identifies the file and line GDB would like to access, but couldn't. I considered changing this, but in the end decided not too, if I extend the existing 'source' annotation to print something in all cases then I risk breaking existing UIs that rely on the file and line always being valid. If I add a new annotation then this might also break existing UIs that rely on GDB itself printing the error from within print_source_line. Given that annotations is deprecated (as I understand it) mechanism for UIs to interact with GDB (in favour of MI) I figure we should just restore the old behaviour, and leave the mini-bugs in until someone actually complains. This isn't a straight revert of the two commits mentioned above. I've left annotate_source_line instead of going back to the original identify_source_line, which lived in source.c, but was really annotation related. The API for setting the current source and line has changed since the original patches, so I updated for that change too. Finally I wrote the code in stack.c so that we avoided an extra level of indentation, which I felt made things easier to read. gdb/ChangeLog: * annotate.c (annotate_source_line): Update return type, add call to update current symtab and line. * annotate.h (annotate_source_line): Update return type, and extend header comment. * source.c (info_line_command): Check annotation_level before calling annotate_source_line. * stack.c (print_frame_info): If calling annotate_source_line returns true, then don't print any other source line information. gdb/testsuite/ChangeLog: * gdb.base/annota1.exp: Update expected results. * gdb.cp/annota2.exp: Update expected results, remove duplicate test name. * gdb.cp/annota3.exp: Update expected results.
2020-05-21gdb: fix -Wtautological-overlap-compare error in lm32-tdep.cSimon Marchi2-1/+5
Building with clang 11, we get: /home/smarchi/src/binutils-gdb/gdb/lm32-tdep.c:84:44: error: overlapping comparisons always evaluate to false [-Werror,-Wtautological-overlap-compare] return ((regnum >= SIM_LM32_EA_REGNUM) && (regnum <= SIM_LM32_BA_REGNUM)) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Indeed, this doesn't make sense, as EA_REGNUM is greater than BA_REGNUM. I'll assume that it was just a mistake and that these two should be swapped. The regnums for BA and EA are contiguous, so ultimately this particular part of the condition is only true if regnum is == EA or == BA. These registers are Exception Address and Breakpoint Address, so I guess it makes sense for them to be in the system register group. The relevant reference is here: https://www.latticesemi.com/-/media/LatticeSemi/Documents/UserManuals/JL/LatticeMico32ProcessorReferenceManual39.ashx?document_id=52077 gdb/ChangeLog: * lm32-tdep.c (lm32_register_reggroup_p): Fix condition.
2020-05-21gdb: remove unnecessary NULL checks before xfreeSimon Marchi11-22/+24
I was inspired by a series of patches merged by Alan Modra in the other projects, so I did the same in GDB with a bit of Coccinelle and grep. This patch removes the unnecessary NULL checks before calls to xfree. They are unnecessary because xfree already does a NULL check. Since free is supposed to handle NULL values correctly, the NULL check in xfree itself is also questionable, but I've left it there for now. gdb/ChangeLog: * coffread.c (patch_type): Remove NULL check before xfree. * corefile.c (set_gnutarget): Likewise. * cp-abi.c (set_cp_abi_as_auto_default): Likewise. * exec.c (build_section_table): Likewise. * remote.c (remote_target::pass_signals): Likewise. * utils.c (n_spaces): Likewise. * cli/cli-script.c (document_command): Likewise. * i386-windows-tdep.c (core_process_module_section): Likewise. * linux-fork.c (struct fork_info) <~fork_info>: Likewise.
2020-05-20gdb: reset/recompute objfile section offsets in reread_symbolsSimon Marchi2-0/+14
This patch started as an investigation of this bug, where the program is re-compiled between two "start" runs: $ ./gdb -nx --data-directory=data-directory -q a.out Reading symbols from a.out... (gdb) start Temporary breakpoint 1 at 0x1131: file test.c, line 1. Starting program: /home/smarchi/build/wt/test/gdb/a.out Temporary breakpoint 1, main () at test.c:1 1 int main() { return 0; } *** re-compile a.out *** (gdb) start The program being debugged has been started already. Start it from the beginning? (y or n) y `/home/smarchi/build/wt/test/gdb/a.out' has changed; re-reading symbols. Temporary breakpoint 2 at 0x555555555129: file test.c, line 1. Starting program: /home/smarchi/build/wt/test/gdb/a.out warning: Probes-based dynamic linker interface failed. Reverting to original interface. Temporary breakpoint 2, main () at test.c:1 1 int main() { return 0; } (gdb) To reproduce the bug, a.out needs to be a position-independent executable (PIE). Here's what happens: 1) We first read the symbols of a.out. The section offsets in the objfile are all 0, so the symbols are created unrelocated. 2) The breakpoint on main is created, as you can see the breakpoint address (derived from the `main` symbol with value 0x1129) is still unrelocated (0x1131). Since the program is not yet started, we don't know at which base address the executable is going to end at. Everything good so far. 3) The execution starts, GDB finds out the executable's base address, fills the objfile's section_offsets vector with a bunch of offsets, and relocates the symbols with those offsets. The latter modifies the symbol values (the `main` symbol is changed from 0x1129 to 0x555555555129). 4) We `start` again, we detect that `a.out` has changed, the `reread_symbols` function kicks in. It tries to reset everything in the `struct objfile` corresponding to `a.out`, except that it leaves the `section_offsets` vector there. 5) `reread_symbols` reads the debug info (calls `read_symbols`). As the DWARF info is read, symbols are created using the old offsets still in `section_offsets`. For example, the `main` symbol is created with the value 0x555555555129. Even though at this point there is no process, so that address is bogus. There's probably more that depends on section_offsets that is not done correctly. 6) Something in the SVR4 solib handling goes wrong, probably because of something that went wrong in (5). I can't quite explain it (if somebody would like to provide a more complete analysis, please go ahead). But this is where it takes a wrong turn: #0 elf_locate_base () at /home/smarchi/src/wt/test/gdb/solib-svr4.c:799 #1 0x000055f0a5bee6d5 in locate_base (info=<optimized out>) at /home/smarchi/src/wt/test/gdb/solib-svr4.c:848 #2 0x000055f0a5bf1771 in svr4_handle_solib_event () at /home/smarchi/src/wt/test/gdb/solib-svr4.c:1955 #3 0x000055f0a5c0ff92 in handle_solib_event () at /home/smarchi/src/wt/test/gdb/solib.c:1258 In the non-working case (without this patch), elf_locate_base returns 0, whereas in the working case (with this patch) it returns a valid address, as we should expect. This patch fixes this by making reread_symbols clear the `section_offsets` vector, and re-create it by calling `sym_offsets`. This is analogous to what syms_from_objfile_1 does. I didn't seem absolutely necessary, but I also made it clear the various `sect_index_*` fields, since their values no longer make sense (they describe the old executable, and are indices in the now cleared sections/section_offsets arrays). I don't really like the approach taken by reread_symbols, trying to reset everything manually on the objfile object, instead of, for example, creating a new one from scratch. But I don't know enough yet to propose a better solution. One more reason I think this patch is needed is that the number of sections of the new executable could be different from the number of sections of the old executable. So if we don't re-create the section_offsets array, not only we'll have wrong offsets, but we could make accesses past the array. Something else that silently fails (but doesn't seem to have consequences) is the prologue analysis when we try to create the breakpoint on `main`. Since the `main` symbol has the wrong value 0x555555555129, we try to access memory in that area, which fails. This can be observed by debugging gdb and using `catch throw`. Before the process is started, we need to access the memory at its unrelocated address, 0x1129, which will read memory from the ELF file. This is now what happens, with this patch applied. It silently fails, probably because commit 46a62268b, "Catch exceptions thrown from gdbarch_skip_prologue", papered over the problem and added an empty catch clause. I'm quite sure that the root cause then was the one fixed by this patch. This fixes tests gdb.ada/exec_changed.exp and gdb.base/reread.exp for me. gdb/ChangeLog: * symfile.c (reread_symbols): Clear objfile's section_offsets vector and section indices, re-compute them by calling sym_offsets.
2020-05-20[PATCH v2 0/9] RISC-V: Support version controling for ISA standard ↵Nelson Chu2-4/+4
extensions and CSR 1. Remove the -mriscv-isa-version and --with-riscv-isa-version options. We can still use -march to choose the version for each extensions, so there is no need to add these. 2. Change the arguments of options from [1p9|1p9p1|...] to [1.9|1.9.1|...]. Unlike the architecture string has specified by spec, ther is no need to do the same thing for options. 3. Spilt the patches to reduce the burdens of review. [PATCH 3/7] RISC-V: Support new GAS options and configure options to set ISA versions to [PATCH v2 3/9] RISC-V: Support GAS option -misa-spec to set ISA versions [PATCH v2 4/9] RISC-V: Support configure options to set ISA versions by default. [PATCH 4/7] RISC-V: Support version checking for CSR according to privilege version. to [PATCH v2 5/9] RISC-V: Support version checking for CSR according to privilege spec version. [PATCH v2 6/9] RISC-V: Support configure option to choose the privilege spec version. 4. Use enum class rather than string to compare the choosen ISA spec in opcodes/riscv-opc.c. The behavior is same as comparing the choosen privilege spec. include * opcode/riscv.h: Include "bfd.h" to support bfd_boolean. (enum riscv_isa_spec_class): New enum class. All supported ISA spec belong to one of the class (struct riscv_ext_version): New structure holds version information for the specific ISA. * opcode/riscv-opc.h (DECLARE_CSR): There are two version information, define_version and abort_version. The define_version means which privilege spec is started to define the CSR, and the abort_version means which privilege spec is started to abort the CSR. If the CSR is valid for the newest spec, then the abort_version should be PRIV_SPEC_CLASS_DRAFT. (DECLARE_CSR_ALIAS): Same as DECLARE_CSR, but only for the obselete CSR. * opcode/riscv.h (enum riscv_priv_spec_class): New enum class. Define the current supported privilege spec versions. (struct riscv_csr_extra): Add new fields to store more information about the CSR. We use these information to find the suitable CSR address when user choosing a specific privilege spec. binutils * dwarf.c: Updated since DECLARE_CSR is changed. opcodes * riscv-opc.c (riscv_ext_version_table): The table used to store all information about the supported spec and the corresponding ISA versions. Currently, only Zicsr is supported to verify the correctness of Z sub extension settings. Others will be supported in the future patches. (struct isa_spec_t, isa_specs): List for all supported ISA spec classes and the corresponding strings. (riscv_get_isa_spec_class): New function. Get the corresponding ISA spec class by giving a ISA spec string. * riscv-opc.c (struct priv_spec_t): New structure. (struct priv_spec_t priv_specs): List for all supported privilege spec classes and the corresponding strings. (riscv_get_priv_spec_class): New function. Get the corresponding privilege spec class by giving a spec string. (riscv_get_priv_spec_name): New function. Get the corresponding privilege spec string by giving a CSR version class. * riscv-dis.c: Updated since DECLARE_CSR is changed. * riscv-dis.c: Add new disassembler option -Mpriv-spec to dump the CSR according to the chosen version. Build a hash table riscv_csr_hash to store the valid CSR for the chosen pirv verison. Dump the direct CSR address rather than it's name if it is invalid. (parse_riscv_dis_option_without_args): New function. Parse the options without arguments. (parse_riscv_dis_option): Call parse_riscv_dis_option_without_args to parse the options without arguments first, and then handle the options with arguments. Add the new option -Mpriv-spec, which has argument. * riscv-dis.c (print_riscv_disassembler_options): Add description about the new OBJDUMP option. ld * testsuite/ld-riscv-elf/attr-merge-arch-01.d: Updated priv attributes according to the -mpriv-spec option. * testsuite/ld-riscv-elf/attr-merge-arch-02.d: Likewise. * testsuite/ld-riscv-elf/attr-merge-arch-03.d: Likewise. * testsuite/ld-riscv-elf/attr-merge-priv-spec-a.s: Likewise. * testsuite/ld-riscv-elf/attr-merge-priv-spec-b.s: Likewise. * testsuite/ld-riscv-elf/attr-merge-priv-spec.d: Likewise. * testsuite/ld-riscv-elf/attr-merge-stack-align.d: Likewise. * testsuite/ld-riscv-elf/attr-merge-strict-align-01.d: Likewise. * testsuite/ld-riscv-elf/attr-merge-strict-align-02.d: Likewise. * testsuite/ld-riscv-elf/attr-merge-strict-align-03.d: Likewise. * testsuite/ld-riscv-elf/attr-merge-strict-align-04.d: Likewise. * testsuite/ld-riscv-elf/attr-merge-strict-align-05.d: Likewise. bfd * elfxx-riscv.h (riscv_parse_subset_t): Add new callback function get_default_version. It is used to find the default version for the specific extension. * elfxx-riscv.c (riscv_parsing_subset_version): Remove the parameters default_major_version and default_minor_version. Add new bfd_boolean parameter *use_default_version. Set it to TRUE if we need to call the callback rps->get_default_version to find the default version. (riscv_parse_std_ext): Call rps->get_default_version if we fail to find the default version in riscv_parsing_subset_version, and then call riscv_add_subset to add the subset into subset list. (riscv_parse_prefixed_ext): Likewise. (riscv_std_z_ext_strtab): Support Zicsr extensions. * elfnn-riscv.c (riscv_merge_std_ext): Use strcasecmp to compare the strings rather than characters. riscv_merge_arch_attr_info): The callback function get_default_version is only needed for assembler, so set it to NULL int the linker. * elfxx-riscv.c (riscv_estimate_digit): Remove the static. * elfxx-riscv.h: Updated. gas * testsuite/gas/riscv/priv-reg-fail-read-only-01.s: Updated. * config/tc-riscv.c (default_arch_with_ext, default_isa_spec): Static variables which are used to set the ISA extensions. You can use -march (or ELF build attributes) and -misa-spec to set them, respectively. (ext_version_hash): The hash table used to handle the extensions with versions. (init_ext_version_hash): Initialize the ext_version_hash according to riscv_ext_version_table. (riscv_get_default_ext_version): The callback function of riscv_parse_subset_t. According to the choosed ISA spec, get the default version for the specific extension. (riscv_set_arch): Set the callback function. (enum options, struct option md_longopts): Add new option -misa-spec. (md_parse_option): Do not call riscv_set_arch for -march. We will call it later in riscv_after_parse_args. Call riscv_get_isa_spec_class to set default_isa_spec class. (riscv_after_parse_args): Call init_ext_version_hash to initialize the ext_version_hash, and then call riscv_set_arch to set the architecture with versions according to default_arch_with_ext. * testsuite/gas/riscv/attribute-02.d: Set 0p0 as default version for x extensions. * testsuite/gas/riscv/attribute-03.d: Likewise. * testsuite/gas/riscv/attribute-09.d: New testcase. For i-ext, we already set it's version to 2p1 by march, so no need to use the default 2p2 version. For m-ext, we do not set the version by -march and ELF arch attribute, so set the default 2p0 to it. For zicsr, it is not defined in ISA spec 2p2, so set 0p0 to it. * testsuite/gas/riscv/attribute-10.d: New testcase. The version of zicsr is 2p0 according to ISA spec 20191213. * config/tc-riscv.c (DEFAULT_RISCV_ARCH_WITH_EXT) (DEFAULT_RISCV_ISA_SPEC): Default configure option settings. You can set them by configure options --with-arch and --with-isa-spec, respectively. (riscv_set_default_isa_spec): New function used to set the default ISA spec. (md_parse_option): Call riscv_set_default_isa_spec rather than call riscv_get_isa_spec_class directly. (riscv_after_parse_args): If the -isa-spec is not set, then we set the default ISA spec according to DEFAULT_RISCV_ISA_SPEC by calling riscv_set_default_isa_spec. * testsuite/gas/riscv/attribute-01.d: Add -misa-spec=2.2, since the --with-isa-spec may be set to different ISA spec. * testsuite/gas/riscv/attribute-02.d: Likewise. * testsuite/gas/riscv/attribute-03.d: Likewise. * testsuite/gas/riscv/attribute-04.d: Likewise. * testsuite/gas/riscv/attribute-05.d: Likewise. * testsuite/gas/riscv/attribute-06.d: Likewise. * testsuite/gas/riscv/attribute-07.d: Likewise. * configure.ac: Add configure options, --with-arch and --with-isa-spec. * configure: Regenerated. * config.in: Regenerated. * config/tc-riscv.c (default_priv_spec): Static variable which is used to check if the CSR is valid for the chosen privilege spec. You can use -mpriv-spec to set it. (enum reg_class): We now get the CSR address from csr_extra_hash rather than reg_names_hash. Therefore, move RCLASS_CSR behind RCLASS_MAX. (riscv_init_csr_hashes): Only need to initialize one hash table csr_extra_hash. (riscv_csr_class_check): Change the return type to void. Don't check the ISA dependency if -mcsr-check isn't set. (riscv_csr_version_check): New function. Check and find the CSR address from csr_extra_hash, according to default_priv_spec. Report warning for the invalid CSR if -mcsr-check is set. (reg_csr_lookup_internal): Updated. (reg_lookup_internal): Likewise. (md_begin): Updated since DECLARE_CSR and DECLARE_CSR_ALIAS are changed. (enum options, struct option md_longopts): Add new GAS option -mpriv-spec. (md_parse_option): Call riscv_set_default_priv_version to set default_priv_spec. (riscv_after_parse_args): If -mpriv-spec isn't set, then set the default privilege spec to the newest one. (enum riscv_csr_class, struct riscv_csr_extra): Move them to include/opcode/riscv.h. * testsuite/gas/riscv/priv-reg-fail-fext.d: This test case just want to check the ISA dependency for CSR, so fix the spec version by adding -mpriv-spec=1.11. * testsuite/gas/riscv/priv-reg-fail-fext.l: Likewise. There are some version warnings for the test case. * gas/testsuite/gas/riscv/priv-reg-fail-read-only-01.d: Likewise. * gas/testsuite/gas/riscv/priv-reg-fail-read-only-01.l: Likewise. * gas/testsuite/gas/riscv/priv-reg-fail-read-only-02.d: Likewise. * gas/testsuite/gas/riscv/priv-reg-fail-rv32-only.d: Likewise. * gas/testsuite/gas/riscv/priv-reg-fail-rv32-only.l: Likewise. * gas/testsuite/gas/riscv/priv-reg-fail-version-1p9.d: New test case. Check whether the CSR is valid when privilege version 1.9 is choosed. * gas/testsuite/gas/riscv/priv-reg-fail-version-1p9.l: Likewise. * gas/testsuite/gas/riscv/priv-reg-fail-version-1p9p1.d: New test case. Check whether the CSR is valid when privilege version 1.9.1 is choosed. * gas/testsuite/gas/riscv/priv-reg-fail-version-1p9p1.l: Likewise. * gas/testsuite/gas/riscv/priv-reg-fail-version-1p10.d: New test case. Check whether the CSR is valid when privilege version 1.10 is choosed. * gas/testsuite/gas/riscv/priv-reg-fail-version-1p10.l: Likewise. * gas/testsuite/gas/riscv/priv-reg-fail-version-1p11.d: New test case. Check whether the CSR is valid when privilege version 1.11 is choosed. * gas/testsuite/gas/riscv/priv-reg-fail-version-1p11.l: Likewise. * config/tc-riscv.c (DEFAULT_RISCV_ISA_SPEC): Default configure option setting. You can set it by configure option --with-priv-spec. (riscv_set_default_priv_spec): New function used to set the default privilege spec. (md_parse_option): Call riscv_set_default_priv_spec rather than call riscv_get_priv_spec_class directly. (riscv_after_parse_args): If -mpriv-spec isn't set, then we set the default privilege spec according to DEFAULT_RISCV_PRIV_SPEC by calling riscv_set_default_priv_spec. * testsuite/gas/riscv/csr-dw-regnums.d: Add -mpriv-spec=1.11, since the --with-priv-spec may be set to different privilege spec. * testsuite/gas/riscv/priv-reg.d: Likewise. * configure.ac: Add configure option --with-priv-spec. * configure: Regenerated. * config.in: Regenerated. * config/tc-riscv.c (explicit_attr): Rename explicit_arch_attr to explicit_attr. Set it to TRUE if any ELF attribute is found. (riscv_set_default_priv_spec): Try to set the default_priv_spec if the priv attributes are set. (md_assemble): Set the default_priv_spec according to the priv attributes when we start to assemble instruction. (riscv_write_out_attrs): Rename riscv_write_out_arch_attr to riscv_write_out_attrs. Update the arch and priv attributes. If we don't set the corresponding ELF attributes, then try to output the default ones. (riscv_set_public_attributes): If any ELF attribute or -march-attr options is set (explicit_attr is TRUE), then call riscv_write_out_attrs to update the arch and priv attributes. (s_riscv_attribute): Make sure all arch and priv attributes are set before any instruction. * testsuite/gas/riscv/attribute-01.d: Update the priv attributes if any ELF attribute or -march-attr is set. If the priv attributes are not set, then try to update them by the default setting (-mpriv-spec or --with-priv-spec). * testsuite/gas/riscv/attribute-02.d: Likewise. * testsuite/gas/riscv/attribute-03.d: Likewise. * testsuite/gas/riscv/attribute-04.d: Likewise. * testsuite/gas/riscv/attribute-06.d: Likewise. * testsuite/gas/riscv/attribute-07.d: Likewise. * testsuite/gas/riscv/attribute-08.d: Likewise. * testsuite/gas/riscv/attribute-09.d: Likewise. * testsuite/gas/riscv/attribute-10.d: Likewise. * testsuite/gas/riscv/attribute-unknown.d: Likewise. * testsuite/gas/riscv/attribute-05.d: Likewise. Also, the priv spec set by priv attributes must be supported. * testsuite/gas/riscv/attribute-05.s: Likewise. * testsuite/gas/riscv/priv-reg-fail-version-1p9.d: Likewise. Updated priv attributes according to the -mpriv-spec option. * testsuite/gas/riscv/priv-reg-fail-version-1p9p1.d: Likewise. * testsuite/gas/riscv/priv-reg-fail-version-1p10.d: Likewise. * testsuite/gas/riscv/priv-reg-fail-version-1p11.d: Likewise. * testsuite/gas/riscv/priv-reg.d: Removed. * testsuite/gas/riscv/priv-reg-version-1p9.d: New test case. Dump the CSR according to the priv spec 1.9. * testsuite/gas/riscv/priv-reg-version-1p9p1.d: New test case. Dump the CSR according to the priv spec 1.9.1. * testsuite/gas/riscv/priv-reg-version-1p10.d: New test case. Dump the CSR according to the priv spec 1.10. * testsuite/gas/riscv/priv-reg-version-1p11.d: New test case. Dump the CSR according to the priv spec 1.11. * config/tc-riscv.c (md_show_usage): Add descriptions about the new GAS options. * doc/c-riscv.texi: Likewise.
2020-05-20gdb/testsuite: check mmap ret val against MAP_FAILEDSimon Marchi5-3/+19
Fixup a few spots in the testsuite that use mmap to consistently check the return value against MAP_FAILED. One spot in gdb.base/coredump-filter.c checked against NULL, that is wrong. The other spots either didn't check, or checked against -1. MAP_FAILED has the value -1, at least on Linux, but it's better to check against the documented define. gdb/testsuite/ChangeLog: PR gdb/26016 * gdb.base/coredump-filter.c (do_mmap): Check mmap ret val against MAP_FAILED. * gdb.base/coremaker.c (mmapdata): Likewise. * gdb.base/jit-reader-host.c (main): Likewise. * gdb.base/sym-file-loader.c (load): Likewise. (load_shlib): Likewise.
2020-05-20Fix array_char_idx.expTom Tromey2-1/+7
Newer versions of GCC can statically initialize an array in the array_char_idx.exp test case. This leads to a spurious failure. This patch fixes the problem by having the test case recognize both possible results. I'm checking this in. gdb/testsuite/ChangeLog 2020-05-20 Tom Tromey <tromey@adacore.com> * gdb.ada/array_char_idx.exp: Recognize initialized array.
2020-05-20Remove bound_name static from ada-lang.cTom Tromey2-14/+14
ada-lang.c has a "bound_name" static that is used when finding fields in a structure in some cases. This patch removes it in favor of computing the desired field name at runtime; this avoids an artificial limit. I'm checking this in. Tested on x86-64 Fedora 30, and also on the internal AdaCore test suite. gdb/ChangeLog 2020-05-20 Tom Tromey <tromey@adacore.com> * ada-lang.c (bound_name, MAX_ADA_DIMENS): Remove. (desc_one_bound, desc_index_type): Compute field name.
2020-05-20[gdb/symtab] Handle .gdb_index in ada language modeTom de Vries6-8/+153
When running test-case gdb.base/with.exp with target board cc-with-gdb-index, we have: ... (gdb) PASS: gdb.base/with.exp: basics: show language with language ada -- print g_s^M 'g_s' has unknown type; cast it to its declared type^M (gdb) FAIL: gdb.base/with.exp: basics: with language ada -- print g_s ... This is due to this bit in dw2_map_matching_symbols: ... if (dwarf2_per_objfile->index_table != nullptr) { /* Ada currently doesn't support .gdb_index (see PR24713). We can get here though if the current language is Ada for a non-Ada objfile using GNU index. As Ada does not look for non-Ada symbols this function should just return. */ return; } ... While the reasoning in the comment may be sound from language perspective, it does introduce an inconsistency in gdb behaviour between: - having a .gdb_index section, and - having a .gdb_names section, or a partial symtab, or -readnow. Fix the inconsistency by completing implementation of dw2_map_matching_symbols. Tested on x86_64-linux, both with native and target board cc-with-debug-index. gdb/ChangeLog: 2020-05-20 Tom de Vries <tdevries@suse.de> PR symtab/25833 * dwarf2/read.c (dw2_map_matching_symbols): Handle .gdb_index. gdb/testsuite/ChangeLog: 2020-05-20 Tom de Vries <tdevries@suse.de> PR symtab/25833 * gdb.base/with-mf-inc.c: New test. * gdb.base/with-mf-main.c: New test. * gdb.base/with-mf.exp: New file.
2020-05-20PR25993, read of freed memoryAlan Modra4-12/+24
ldmain.c:add_archive_element copies file name pointers from the bfd to a lang_input_statement_type. input->filename = abfd->filename; input->local_sym_name = abfd->filename; This results in stale pointers when twiddling the bfd filename in places like the pe ld after_open. So don't free the bfd filename, and make copies using bfd_alloc memory that won't result in small memory leaks that annoy memory checkers. PR 25993 bfd/ * archive.c (_bfd_get_elt_at_filepos): Don't strdup filename, use bfd_set_filename. * elfcode.h (_bfd_elf_bfd_from_remote_memory): Likewise. * mach-o.c (bfd_mach_o_fat_member_init): Likewise. * opncls.c (bfd_fopen, bfd_openstreamr, bfd_openr_iovec, bfd_openw), (bfd_create): Likewise. (_bfd_delete_bfd): Don't free filename. (bfd_set_filename): Copy filename param to bfd_alloc'd memory, return pointer to the copy or NULL on alloc fail. * vms-lib.c (_bfd_vms_lib_get_module): Free newname and test result of bfd_set_filename. * bfd-in2.h: Regenerate. gdb/ * solib-darwin.c (darwin_bfd_open): Don't strdup pathname for bfd_set_filename. * solib-aix.c (solib_aix_bfd_open): Use std::string for name passed to bfd_set_filename. * symfile-mem.c (add_vsyscall_page): Likewise for string passed to symbol_file_add_from_memory. (symbol_file_add_from_memory): Make name param a const char* and don't strdup. ld/ * emultempl/pe.em (gld_${EMULATION_NAME}_after_open): Don't copy other_bfd_filename for bfd_set_filename, and test result of bfd_set_filename call. Don't create a new is->filename, simply copy from bfd filename. Free new_name after bfd_set_filename. * emultempl/pep.em (gld_${EMULATION_NAME}_after_open): Likewise.
2020-05-20Use bfd_get_filename throughout gdbAlan Modra8-12/+25
This patch makes gdb use the inline accessor for all bfd->filename read accesses. * coff-pe-read.c (read_pe_exported_syms): Use bfd_get_filename rather than accessing bfd->filename directly. * dtrace-probe.c (dtrace_static_probe_ops::get_probes): Likewise, and use bfd_section_name. * dwarf2/frame.c (decode_frame_entry): Likewise. * exec.c (exec_set_section_address): Likewise. * solib-aix.c (solib_aix_bfd_open): Likewise. * stap-probe.c (get_stap_base_address): Likewise. * symfile.c (reread_symbols): Likewise.
2020-05-19Restore missing Rust testTom Tromey2-1/+5
An earlier patch inadvertently broke a Rust test. This restores it. gdb/testsuite/ChangeLog 2020-05-19 Tom Tromey <tromey@adacore.com> * gdb.rust/simple.exp: Restore missing test result.
2020-05-19[gdb/testsuite] Fix typo in gdb.base/gdb-caching-proc.expTom de Vries2-1/+5
Fix intial -> initial typo. gdb/testsuite/ChangeLog: 2020-05-19 Tom de Vries <tdevries@suse.de> * gdb.base/gdb-caching-proc.exp: Fix typo.
2020-05-19Fix duplicate tests in gdb.rustTom Tromey2-8/+15
gdb.rust complains about some duplicate test names. This patch fixes this in a straightforward way. 2020-05-19 Tom Tromey <tromey@adacore.com> * gdb.rust/simple.exp: Add some test descriptions. (test_one_slice): Use with_test_prefix.
2020-05-19Update call to target_fileio_openTom Tromey2-1/+5
An earlier patch changed target_fileio_open, but missed a caller. This patch fixes it. 2020-05-19 Tom Tromey <tromey@adacore.com> * sparc64-tdep.c (adi_tag_fd): Update call to target_fileio_open.
2020-05-19gdb: fix off-by-one error in quirk_rust_enumSimon Marchi2-1/+5
Found by inspection, so I don't have a test for it (I don't think it would be easy to have this bug cause a failure reliably). We allocate space for N fields into `new_fields`, then memcpy N fields at `new_fields + 1`. This overflows the allocated buffer by one field. Fix it by allocating `N + 1` fields. gdb/ChangeLog: * dwarf2/read.c (quirk_rust_enum): Allocate enough fields.
2020-05-19Make exec-file-mismatch compare build IDsPedro Alves7-36/+100
The patch makes GDB do exec-file-mismatch validation by comparing build IDs instead of the current method of comparing filenames. Currently, the exec-file-mismatch feature simply compares filenames to decide whether the exec file loaded in gdb and the exec file the target reports is running match. This causes false positives when remote debugging, because it'll often be the case that the paths in the host and the target won't match. And of course misses the case of the files having the same name but being actually different files (e.g., different builds). This also broke many testcases when running against gdbserver, causing tests to be skipped like (here native-extended-gdbserver): (gdb) run Starting program: /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.base/argv0-symlink/argv0-symlink-filelink warning: Mismatch between current exec-file /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.base/argv0-symlink/argv0-symlink-filelink and automatically determined exec-file /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.base/argv0-symlink/argv0-symlink exec-file-mismatch handling is currently "ask" Load new symbol table from "/home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.base/argv0-symlink/argv0-symlink"? (y or n) UNTESTED: gdb.base/argv0-symlink.exp: could not run to main or to fail like (here native-gdbserver): (gdb) spawn /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/../../gdbserver/gdbserver --once localhost:2346 /home/pedro/gdb/binutils-gdb/build/gdb/te stsuite/outputs/gdb.btrace/buffer-size/skip_btrace_tests-19968.x Process /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.btrace/buffer-size/skip_btrace_tests-19968.x created; pid = 20040 Listening on port 2346 target remote localhost:2346 Remote debugging using localhost:2346 warning: Mismatch between current exec-file /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/temp/19968/skip_btrace_tests-19968.x and automatically determined exec-file /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.btrace/buffer-size/skip_btrace_tests-19968.x exec-file-mismatch handling is currently "ask" Load new symbol table from "/home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.btrace/buffer-size/skip_btrace_tests-19968.x"? (y or n) Quit (gdb) UNSUPPORTED: gdb.btrace/buffer-size.exp: target does not support record-btrace The former case is about GDB not realizing the two files are the same, because one of the them is a symlink to the other. The latter case is about GDB realizing that one file is a copy of the other. Over the years, the toolchain has settled on build ID matching being the canonical method to match core dumps to executables, and executables with no debug info to their debug info. This patch makes us use build IDs to match the running image of a binary with its version loaded in gdb, which may or may not have debug info. This is very much like the core dump/executable matching. The change to gdb_bfd_open is necessary to get rid of the "transfers from remote targets can be slow" warning when we open the remote file to read its build ID: (gdb) r Starting program: /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.base/break/break Reading /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.base/argv0-symlink/argv0-symlink from remote target... warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ warning: Mismatch between current exec-file /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.base/break/break and automatically determined exec-file /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.base/argv0-symlink/argv0-symlink exec-file-mismatch handling is currently "ask" Load new symbol table from "/home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.base/argv0-symlink/argv0-symlink"? (y or n) While trying this out, I was worried that bfd would read a lot of stuff from the binary in order to extract the build ID, making it potentially slow, but turns out we don't read all that much. Maybe a couple hundred bytes, and most of it seemingly is the read-ahead cache. So I'm not worried about that. Otherwise I'd consider whether a new qXfer:buildid:read would be better. But I'm happy that we seemingly don't need to worry about it. gdb/ChangeLog: 2020-05-19 Pedro Alves <palves@redhat.com> * NEWS (set exec-file-mismatch): Adjust entry. * exec.c: Include "build-id.h". (validate_exec_file): Try to match build IDs instead of filenames. * gdb_bfd.c (struct gdb_bfd_open_closure): New. (gdb_bfd_iovec_fileio_open): Adjust to use gdb_bfd_open_closure and pass down 'warn_if_slow'. (gdb_bfd_open): Add 'warn_if_slow' parameter. Use gdb_bfd_open_closure to pass it down. * gdb_bfd.h (gdb_bfd_open): Add 'warn_if_slow' parameter. gdb/doc/ChangeLog: 2020-05-19 Pedro Alves <palves@redhat.com> * gdb.texinfo (Attach): Update exec-file-mismatch description to mention build IDs. (Separate Debug Files): Add "build id" anchor.
2020-05-19Eliminate target_fileio_open_warn_if_slowPedro Alves4-46/+26
This basically makes target_fileio_open_1 extern, renamed to target_fileio_open, and eliminates the current target_fileio_open_warn_if_slow and target_fileio_open. A following parameter will want to change gdb_bfd_iovec_fileio_open, the only caller of target_fileio_open_warn_if_slow, to pass down "warn_if_slow" true/false from the caller, instead of hardcoding "warn_if_slow" true. gdb/ChangeLog: 2020-05-19 Pedro Alves <palves@redhat.com> * gdb_bfd.c (gdb_bfd_iovec_fileio_open): Adjust. * target.c (target_fileio_open_1): Rename to target_fileio_open and make extern. Use bool. (target_fileio_open, target_fileio_open_warn_if_slow): Delete. (target_fileio_read_alloc_1): Adjust. * target.h (target_fileio_open): Add 'warn_if_slow' parameter. (target_fileio_open_warn_if_slow): Delete declaration.
2020-05-19Default gdb_bfd_open's fd parameter to -1Pedro Alves10-13/+19
A following patch will add one more defaulted parameter. gdb/ChangeLog: 2020-05-19 Pedro Alves <palves@redhat.com> * gdb_bfd.h: (gdb_bfd_open): Default to 'fd' parameter to -1. Adjust all callers.
2020-05-19gdb: fix -Wtautological-overlap-compare error in h8300-tdep.cYoshinori Sato2-6/+12
Compiling with clang 11 gives us: CXX h8300-tdep.o /home/smarchi/src/binutils-gdb/gdb/h8300-tdep.c:225:21: error: overlapping comparisons always evaluate to false [-Werror,-Wtautological-overlap-compare] if (disp < 0 && disp > 0xffffff) ~~~~~~~~~^~~~~~~~~~~~~~~~~~ /home/smarchi/src/binutils-gdb/gdb/h8300-tdep.c:203:17: error: overlapping comparisons always evaluate to false [-Werror,-Wtautological-overlap-compare] if (disp < 0 && disp > 0xffffff) ~~~~~~~~~^~~~~~~~~~~~~~~~~~ /home/smarchi/src/binutils-gdb/gdb/h8300-tdep.c:184:17: error: overlapping comparisons always evaluate to false [-Werror,-Wtautological-overlap-compare] if (disp < 0 && disp > 0xffffff) ~~~~~~~~~^~~~~~~~~~~~~~~~~~ Indeed, disp (of type LONGEST) can't be less than 0 and greater than 0xffffff. Fix it by changing the way we check if disp is negative. Check the sign bit of disp, which is a 24-bit number. gdb/ChangeLog: * h8300-tdep.c (h8300_is_argument_spill): Change how we check whether disp is negative.
2020-05-19gdb: make symfile_segment_data::segment_info an std::vectorSimon Marchi4-8/+15
Change the symfile_segment_data::segment_info array to be an std::vector. No functional changes are expected. gdb/ChangeLog: * symfile.h (struct symfile_segment_data) <~symfile_segment_data>: Remove. <segment_info>: Change to std::vector. * symfile.c (default_symfile_segments): Update. * elfread.c (elf_symfile_segments): Update.
2020-05-19gdb: use std::vector to store segments in symfile_segment_dataSimon Marchi6-41/+45
Instead of maintaining two vectors, I added a small `segment` class which holds both the base address and size of one segment and replaced the two `segment_bases` and `segment_sizes` arrays with a single vector. The rest of the changes are straightforward, no behavior changes are expected. gdb/ChangeLog: * symfile.h (struct symfile_segment_data) <struct segment>: New. <segments>: New. <segment_bases, segment_sizes>: Remove. * symfile.c (default_symfile_segments): Update. * elfread.c (elf_symfile_segments): Update. * remote.c (remote_target::get_offsets): Update. * solib-target.c (solib_target_relocate_section_addresses): Update.
2020-05-19gdb: allocate symfile_segment_data with newSimon Marchi7-45/+55
- Allocate this structure with new instead of XNEW, use a unique pointer to manage its lifetime. - Change a few functions to return a unique pointer instead of a plain pointer. - Change free_symfile_segment_data to be symfile_segment_data's destructor. gdb/ChangeLog: * symfile.h (struct symfile_segment_data): Initialize fields. <~symfile_segment_data>: Add. (symfile_segment_data_up): New. (struct sym_fns) <sym_segments>: Return a symfile_segment_data_up. (default_symfile_segments): Return a symfile_segment_data_up. (free_symfile_segment_data): Remove. (get_symfile_segment_data): Return a symfile_segment_data_up. * symfile.c (default_symfile_segments): Likewise. (get_symfile_segment_data): Likewise. (free_symfile_segment_data): Remove. (symfile_find_segment_sections): Update. * elfread.c (elf_symfile_segments): Return a symfile_segment_data_up. * remote.c (remote_target::get_offsets): Update. * solib-target.c (solib_target_relocate_section_addresses): Update. * symfile-debug.c (debug_sym_segments): Return a symfile_segment_data_up.
2020-05-18Avoid short i386 register names on Solaris/x86 [PR25981]Rainer Orth2-4/+20
This is the 32-bit companion to Remove unused ps_lgetLDT etc. on Solaris/x86 [PR25981] https://sourceware.org/pipermail/gdb-patches/2020-May/168713.html A 32-bit-default gdb fails to compile with the updated <sys/regset.h>. While it is also affected by the lack of a GS definition, which the compantion patch above fixes, it also fails to compile i386-sol2-nat.c like this /vol/src/gnu/gdb/hg/master/git/gdb/i386-sol2-nat.c:181:3: error: 'EAX' was not declared in this scope 181 | EAX, ECX, EDX, EBX, | ^~~ and several more. While this could be fixed by either including <ucontext.h> here or provding fallback definitions of the register macros, I chose to do what the 64-bit-default code in the same file (amd64_sol2_gregset32_reg_offset[]) does, namely just hardcode the numeric values instead. They are part of the ABI and thus guaranteed not to change. With this patch, a i386-pc-solaris2.11 configuration on master compiles again, however, it doesn't work. However, I could successfully test it on the gdb-9 branch. Compiling and testing proved to be messy, unfortunately: * For one, Solaris <sys/procfs.h> and largefile support used to be mutually exclusive (fixed in Solaris 11.4 and Illumos), which was exacerbated by the fact that g++ predefines _FILE_OFFSET_BITS=64 since GCC 9.1.0. For now I've worked around this by adding -U_FILE_OFFSET_BITS to CXXFLAGS and configuring with --disable-largefile. I hope to clean this up in a future patch. * gdb still defaults to startup-with-shell on. However, /bin/bash is a 64-bit executable which cannot be debugged by a 32-bit gdb. I hacked around that part by pointing $SHELL at a 32-bit bash before running make check. PR build/25981 * i386-sol2-nat.c [PR_MODEL_NATIVE != PR_MODEL_LP64] (regmap): Hardcode register numbers.
2020-05-18Remove unused ps_lgetLDT etc. on Solaris/x86 [PR25981]Rainer Orth4-117/+10
As reported in PR build/25981, a future Solaris 11.4 update will soon remove the short i386 register names like SS etc. from <sys/regset.h>. They could leak into user code (e.g. via <signal.h> -> <sys/signal.h> -> <sys/ucontext.h>) and pollute the user namespace. Affected code would have a hard time avoiding the issue: LLVM is one of those. While the short names are required to be present by the i386 psABI, that document only demands that they exist in <ucontext.h>, which is what the upcoming update assures. With this change, in a 64-bit-default configuration, procfs.c fails to compile on Solaris/x86: /vol/src/gnu/gdb/hg/master/git/gdb/procfs.c: In function 'ssd* procfs_find_LDT_entry(ptid_t)': /vol/src/gnu/gdb/hg/master/git/gdb/procfs.c:1643:18: error: 'GS' was not declared in this scope 1643 | key = (*gregs)[GS] & 0xffff; | ^~ make[2]: *** [Makefile:1607: procfs.o] Error 1 Initially I meant to provide a definition using the planned replacement macro, but closer inspection revealed a better way. procfs_find_LDT_entry and its helper proc_get_LDT_entry are only used to implement ps_lgetLDT, one of the callback functions required by libthread_db.so.1 (cf. <proc_service.h>). While that function is still documented as being required even in Solaris 11.4, I found that calls to it had been removed long ago in Solaris 9, so just removing the three functions above is the easiest fix. The following patch does just that. It compiled successfully on amd64-pc-solaris2.11, however, as reported in PR gdb/25939, master is completely broken on Solaris since the multi-target patch. The patch applies cleanly to the gdb-9 branch and there I could test it successfully. PR build/25981 * procfs.c [(__i386__ || __x86_64__) && sun] (proc_get_LDT_entry, procfs_find_LDT_entry): Remove. * procfs.h [(__i386__ || __x86_64__) && sun] (struct ssd, procfs_find_LDT_entry): Remove. * sol-thread.c [(__i386__ || __x86_64__) && sun] (ps_lgetLDT): Remove.
2020-05-18[gdb/testsuite] Use with_test_prefix in gdb.base/gdb-caching-proc.expTom de Vries2-18/+28
When running test-case gdb.base/gdb-caching-proc.exp all passes are unique, but fails might not be. Fix this by using with_test_prefix. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-05-18 Tom de Vries <tdevries@suse.de> * gdb.base/gdb-caching-proc.exp: Use with_test_prefix.
2020-05-17Stop considering hw and sw breakpoint locations duplicates (PR gdb/25741)Pedro Alves4-86/+267
In the following conditions: - A target with hardware breakpoints available, and - A target that uses software single stepping, - An instruction at ADDRESS loops back to itself, Now consider the following steps: 1. The user places a hardware breakpoint at ADDRESS (an instruction that loops to itself), 2. The inferior runs and hits the breakpoint at ADDRESS, 3. The user tells GDB to 'continue'. In #3 when the user tells GDB to continue, GDB first disables the hardware breakpoint at ADDRESS, and then inserts a software single-step breakpoint at ADDRESS. The original user-created breakpoint was a hardware breakpoint, while the single-step breakpoint will be a software breakpoint. GDB continues and immediately hits the software single-step breakpoint. GDB then deletes the software single-step breakpoint by calling delete_single_step_breakpoints, which eventually calls delete_breakpoint, which, once the breakpoint (and its locations) are deleted, calls update_global_location_list. During update_global_location_list GDB spots that we have an old location (the software single step breakpoint location) that is inserted, but being deleted, and a location (the original hardware breakpoint) at the same address which we are keeping, but which is not currently inserted, GDB then calls breakpoint_locations_match on these two locations. Currently the locations do match, and so GDB calls swap_insertion which swaps the "inserted" state of the two locations. The user created hardware breakpoint is marked as inserted, while the GDB internal software single step breakpoint is now marked as not inserted. After this GDB returns through the call stack and leaves delete_single_step_breakpoints. After this GDB continues with its normal "stopping" process, as part of this stopping process GDB removes all the breakpoints from the target. Due to the swap it is now the user-created hardware breakpoint that is marked as inserted, so it is this breakpoint GDB tries to remove. The problem is that GDB inserted the software single-step breakpoint as a software breakpoint, but is now trying to remove the hardware breakpoint. The problem is removing a software breakpoint is very different to removing a hardware breakpoint, this could result is some undetected undefined behaviour, or as in the original bug report (PR gdb/25741), could result in the target throwing an error. With "set breakpoint always-inserted on", we can easily reproduce this against GDBserver. E.g.: (gdb) hbreak main Sending packet: $m400700,40#28...Packet received: 89e58b.... Sending packet: $m400736,1#fe...Packet received: 48 Hardware assisted breakpoint 1 at 0x400736: file threads.c, line 57. Sending packet: $Z1,400736,1#48...Packet received: OK Packet Z1 (hardware-breakpoint) is supported (gdb) b main Note: breakpoint 1 also set at pc 0x400736. Sending packet: $m400736,1#fe...Packet received: 48 Breakpoint 2 at 0x400736: file threads.c, line 57. (gdb) del Delete all breakpoints? (y or n) y Sending packet: $z0,400736,1#67...Packet received: E01 warning: Error removing breakpoint 2 This patch adds a testcase that does exactly that. Trying to enhance GDB to handle this scenario while continuing to avoid inserting redundant software and hardware breakpoints at the same address turns out futile, because, given non-stop and breakpoints always-inserted, if the user: #1 - inserts a hw breakpoint, then #2 - inserts a sw breakpoint at the same address, and then #3 - removes the original hw breakpoint, GDB would have to make sure to insert the sw breakpoint before removing the hw breakpoint, to avoid running threads missing the breakpoint. I.e., there's always going to be a window where a target needs to be able to handle both sw and a hw breakpoints installed at the same address. You can see more detailed description of that issue here: https://sourceware.org/pipermail/gdb-patches/2020-April/167738.html So the fix here is to just stop considering software breakpoints and hw breakpoints duplicates, and let GDB insert sw and hw breakpoints at the same address. The central change is to make breakpoint_locations_match consider the location's type too. There are several other changes necessary to actually make that that work correctly, however: - We need to handle the duplicates detection better. Take a look at the loop at the tail end of update_global_location_list. Currently, because breakpoint locations aren't sorted by type, we can end up with, at the same address, a sw break, then a hw break, then a sw break, etc. The result is that that second sw break won't be considered a duplicate of the first sw break. Seems like we already handle that incorrectly for range breakpoints. - The "set breakpoint auto-hw on" handling is moved out of insert_bp_location to update_global_location_list, before the duplicates determination. Moving "set breakpoint auto-hw off" handling as well and downgrading it to a warning+'disabling the location' was considered too, but in the end discarded, because we want to error out with internal and momentary breakpoints, like software single-step breakpoints. Disabling such locations at update_global_location_list time would make GDB lose control of the inferior. - In update_breakpoint_locations, the logic of matching old locations with new locations, in the have_ambiguous_names case, is updated to still consider sw vs hw locations the same. - Review all ALL_BP_LOCATIONS_AT_ADDR uses, and update those that might need to be updated, and update comments for those that don't. Note that that macro walks all locations at a given address, and doesn't call breakpoint_locations_match. The result against GDBserver (with "set breakpoint condition-evaluation host" to avoid seeing confusing reinsertions) is: (gdb) hbreak main Sending packet: $m400736,1#fe...Packet received: 48 Hardware assisted breakpoint 1 at 0x400736: file main.c, line 57. Sending packet: $Z1,400736,1#48...Packet received: OK (gdb) b main Note: breakpoint 1 also set at pc 0x400736. Sending packet: $m400736,1#fe...Packet received: 48 Breakpoint 4 at 0x400736: file main.c, line 57. Sending packet: $Z0,400736,1#47...Packet received: OK (gdb) del 3 Sending packet: $z1,400736,1#68...Packet received: OK gdb/ChangeLog: 2020-05-17 Pedro Alves <palves@redhat.com> Andrew Burgess <andrew.burgess@embecosm.com> Keno Fischer <keno@juliacomputing.com> PR gdb/25741 * breakpoint.c (build_target_condition_list): Update comments. (build_target_command_list): Update comments and skip matching locations. (insert_bp_location): Move "set breakpoint auto-hw on" handling to a separate function. Simplify "set breakpoint auto-hw off" handling. (insert_breakpoints): Update comment. (tracepoint_locations_match): New parameter. For breakpoints, compare location types too, if the caller wants to. (handle_automatic_hardware_breakpoints): New functions. (bp_location_is_less_than): Also sort by location type and hardware breakpoint length. (update_global_location_list): Handle "set breakpoint auto-hw on" here. (update_breakpoint_locations): Ask breakpoint_locations_match to ignore location types. gdb/testsuite/ChangeLog: 2020-05-17 Pedro Alves <palves@redhat.com> PR gdb/25741 * gdb.base/hw-sw-break-same-address.exp: New file.
2020-05-16Fix gdb.multi/multi-re-run.exp with native-gdbserverPedro Alves2-0/+12
The new exec-file-mismatch feature reveals that when running gdb.multi/multi-re-run.exp against --target_board=native-gdbserver, we've been starting gdbserver with the wrong program: (gdb) spawn /home/pedro/brno/pedro/gdb/binutils-gdb/build/gdb/testsuite/../../gdbserver/gdbserver --once localhost:2347 /home/pedro/brno/pedro/gdb/binutils-gdb/build/gdb/te stsuite/outputs/gdb.multi/multi-re-run/multi-re-run-2 Process /home/pedro/brno/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.multi/multi-re-run/multi-re-run-2 created; pid = 6280 Listening on port 2347 target remote localhost:2347 Remote debugging using localhost:2347 warning: Mismatch between current exec-file /home/pedro/brno/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.multi/multi-re-run/multi-re-run-1 and automatically determined exec-file /home/pedro/brno/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.multi/multi-re-run/multi-re-run-2 exec-file-mismatch handling is currently "ask" Load new symbol table from "/home/pedro/brno/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.multi/multi-re-run/multi-re-run-2"? (y or n) Quit (gdb) FAIL: gdb.multi/multi-re-run.exp: re_run_inf=1: iter=1: running to all_started in runto The problem is that gdb_reload uses the last loaded file as binary to spawn, but we load the program for inferior 2 and then switch to inferior 1 and run it, so the last loaded file is the program for inferior 2. Fix this by tweaking last_loaded_file. gdb/testsuite/ChangeLog: 2020-05-16 Pedro Alves <palves@redhat.com> * gdb.multi/multi-re-run.exp (test_re_run): Switch LAST_LOADED_FILE accordingly.
2020-05-16gdb: remove TYPE_NAME macroSimon Marchi46-331/+334
Remove `TYPE_NAME`, changing all the call sites to use `type::name` directly. This is quite a big diff, but this was mostly done using sed and coccinelle. A few call sites were done by hand. gdb/ChangeLog: * gdbtypes.h (TYPE_NAME): Remove. Change all cal sites to use type::name instead.
2020-05-16gdb: add type::name / type::set_nameSimon Marchi21-99/+114
Add the `name` and `set_name` methods on `struct type`, in order to remove the `TYPE_NAME` macro. In this patch, the `TYPE_NAME` macro is changed to use `type::name`, so all the call sites that are used to set the type name are changed to use `type::set_name`. The next patch will remove `TYPE_NAME` completely. gdb/ChangeLog: * gdbtypes.h (struct type) <name, set_name>: New methods. (TYPE_CODE): Use type::name. Change all call sites used to set the name to use type::set_name instead.
2020-05-16Remove ALL_UISTom Tromey4-7/+16
Continuing my goal of removing the "ALL_*" iterator macros, this removes ALL_UIS, replacing it with an iterator adaptor. gdb/ChangeLog 2020-05-16 Tom Tromey <tom@tromey.com> * top.c (quit_force): Update. * infrun.c (handle_no_resumed): Update. * top.h (all_uis): New function. (ALL_UIS): Remove.