aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-12-10Remove spurious newline on debug printfLuis Machado2-1/+5
I noticed a spurious newline on infrun debugging output. The following patch fixes that. I'll push as obvious. gdb/ChangeLog: 2020-12-10 Luis Machado <luis.machado@linaro.org> * breakpoint.c (should_be_inserted): Don't output newline.
2020-12-10[AArch64] SVE/FPSIMD fixup for big endianLuis Machado7-35/+246
The FPSIMD dump in signal frames and ptrace FPSIMD dump in the SVE context structure follows the target endianness, whereas the SVE dumps are endianness-independent (LE). Therefore, when the system is in BE mode, we need to reverse the bytes for the FPSIMD data. Given the V registers are larger than 64-bit, I've added a way for value bytes to be set, as opposed to passing a 64-bit fixed quantity. This fits nicely with the unwinding *_got_bytes function and makes the trad-frame more flexible and capable of saving larger registers. The memory for the bytes is allocated via the frame obstack, so it gets freed after we're done inspecting the frame. gdb/ChangeLog: 2020-12-10 Luis Machado <luis.machado@linaro.org> * aarch64-linux-tdep.c (aarch64_linux_restore_vreg) New function. (aarch64_linux_sigframe_init): Call aarch64_linux_restore_vreg. * aarch64-tdep.h (V_REGISTER_SIZE): Move to ... * arch/aarch64.h: ... here. * nat/aarch64-sve-linux-ptrace.c: Include endian.h. (aarch64_maybe_swab128): New function. (aarch64_sve_regs_copy_to_reg_buf) (aarch64_sve_regs_copy_from_reg_buf): Adjust FPSIMD entries. * trad-frame.c (trad_frame_reset_saved_regs): Initialize the data field. (TF_REG_VALUE_BYTES): New enum value. (trad_frame_value_bytes_p): New function. (trad_frame_set_value_bytes): New function. (trad_frame_set_reg_value_bytes): New function. (trad_frame_get_prev_register): Handle register values saved as bytes. * trad-frame.h (trad_frame_set_reg_value_bytes): New prototype. (struct trad_frame_saved_reg) <data>: New field. (trad_frame_set_value_bytes): New prototype. (trad_frame_value_bytes_p): New prototype.
2020-12-10gdb: move bfd_open_from_target_memory to gdb_bfdMihails Strasuns4-83/+99
This function allows to create a BFD handle using an accessible memory range in a target memory. It is currently contained in a JIT module but this functionality may be of wider usefullness - for example, reading ELF binaries contained within a core dump. gdb/ChangeLog: 2020-12-07 Mihails Strasuns <mihails.strasuns@intel.com> * jit.c (mem_bfd*, bfd_open_from_target_memory): Removed. * gdb_bfd.h (gdb_bfd_open_from_target_memory): New function. * gdb_bfd.c (mem_bfd*, gdb_bfd_open_from_target_memory): New functions.
2020-12-10RISC-V: Add sext.[bh] and zext.[bhw] pseudo instructions.Nelson Chu9-0/+188
https://github.com/riscv/riscv-asm-manual/pull/61 We aleady have sext.w, so just add sext.b, sext.h, zext.b, zext.h and zext.w. In a certain sense, zext.b is not a pseudo - It is an alias of andi. Similarly, sext.b and sext.h are aliases of other rvb instructions, when we enable b extension; But they are pseudos when we just enable rvi. However, this patch does not consider the rvb cases. Besides, zext.w is only valid in rv64. gas/ * config/tc-riscv.c (riscv_ext): New function. Use md_assemblef to expand the zext and sext pseudos, to give them a chance to be expanded into c-ext instructions. (macro): Handle M_ZEXTH, M_ZEXTW, M_SEXTB and M_SEXTH. * testsuite/gas/riscv/ext.s: New testcase. * testsuite/gas/riscv/ext-32.d: Likewise. * testsuite/gas/riscv/ext-64.d: Likewise. include/ * opcode/riscv.h (M_ZEXTH, M_ZEXTW, M_SEXTB, M_SEXTH.): Added. opcodes/ * riscv-opc.c (riscv_opcodes): Add sext.[bh] and zext.[bhw].
2020-12-10RISC-V: Dump CSR according to the elf privileged spec attributes.Nelson Chu4-4/+47
opcodes/ * disassemble.h (riscv_get_disassembler): Declare. * disassemble.c (disassembler): Changed to riscv_get_disassembler. * riscv-dis.c (riscv_get_disassembler): Check the elf privileged spec attributes before calling print_insn_riscv. (parse_riscv_dis_option): Same as the assembler, the priority of elf attributes are higher than the options. If we find the privileged attributes, but the -Mpriv-spec= is different, then output error/warning and still use the elf attributes set.
2020-12-10RISC-V: Control fence.i and csr instructions by zifencei and zicsr.Nelson Chu15-53/+179
bfd/ * elfxx-riscv.c (riscv_ext_dont_care_version): New function. Return TRUE if we don't care the versions of the extensions. These extensions are added to the subset list for special purposes, with the explicit versions or the RISCV_UNKNOWN_VERSION versions. (riscv_parse_add_subset): If we do care the versions of the extension, and the versions are unknown, then report errors for the non-implicit extensions, and return directly for the implicit one. (riscv_arch_str1): Do not output i extension after e, and the extensions which versions are unknown. gas/ * config/tc-riscv.c (riscv_multi_subset_supports): Handle INSN_CLASS_ZICSR and INSN_CLASS_ZIFENCEI. * testsuite/gas/riscv/march-imply-i.s: New testcase. * testsuite/gas/riscv/march-imply-i2p0-01.d: New testcase. The version of i is less than 2.1, and zi* are supported in the chosen spec, so enable the fence.i and csr instructions, also output the implicit zi* to the arch string. * testsuite/gas/riscv/march-imply-i2p0-02.d: Likewise, but the zi* are not supported in the spec 2.2. Enable the related instructions since i's version is less than 2.1, but do not output them. * testsuite/gas/riscv/march-imply-i2p1-01.d: New testcase. The version of i is 2.1, so don't add it's implicit zi*, and disable the related instructions. * testsuite/gas/riscv/march-imply-i2p1-01.l: Likewise. * testsuite/gas/riscv/march-imply-i2p1-02.d: Likewise, and set the zi* explicitly, so enable the related instructions. * testsuite/gas/riscv/march-imply-i2p0.d: Removed. * testsuite/gas/riscv/march-imply-i2p1.d: Removed. include/ * opcode/riscv.h: Add INSN_CLASS_ZICSR and INSN_CLASS_ZIFENCEI. opcodes/ * riscv-opc.c (riscv_opcodes): Control fence.i and csr instructions by zifencei and zicsr.
2020-12-10Automatic date update in version.inGDB Administrator1-1/+1
2020-12-09Use add_angle_brackets in ada_lookup_encoded_symbolTom Tromey2-1/+5
Joel recently pointed out add_angle_brackets to me. This patch changes one spot in ada-lang.c to use this function rather than doing it on its own. gdb/ChangeLog 2020-12-09 Tom Tromey <tromey@adacore.com> * ada-lang.c (ada_lookup_encoded_symbol): Use add_angle_brackets.
2020-12-09Handle 128-bit constants for fixed pointTom Tromey2-34/+57
In some cases, GNAT can emit 128-bit constants for fixed-point types. This patch changes gdb to handle this scenario, by changing the low-level rational-reading functions in dwarf2/read.c to work directly with gdb_mpz values. (I'm not sure offhand if these 128-bit patches have gone into upstream GCC yet -- but they will eventually, and meanwhile I think it should be clear that this patch is otherwise harmless.) gdb/ChangeLog 2020-12-09 Tom Tromey <tromey@adacore.com> * dwarf2/read.c (get_dwarf2_rational_constant): Change "numerator" and "denominator" to gdb_mpz. Handle block forms. (get_dwarf2_unsigned_rational_constant): Change "numerator" and "denominator" to gdb_mpz. (finish_fixed_point_type): Update. (has_zero_over_zero_small_attribute): Update.
2020-12-09Unify all operators into std-operator.defTom Tromey6-144/+113
This removes ada-operator.def and fortran-operator.def, merging their contents into std-operator.def. Note that the comment for OP_EXTENDED0 is a bit wrong. IMO this constant could be removed, as it is only used for a single assert that does not provide much value. However, I haven't done so here. gdb/ChangeLog 2020-12-09 Tom Tromey <tromey@adacore.com> * expprint.c (op_name): Update. * expression.h (enum exp_opcode): Update. * std-operator.def: Add more opcodes. * ada-operator.def, fortran-operator.def: Remove, moving contents into std-operator.def.
2020-12-09gdb: address review comments of previous seriesSimon Marchi2-6/+15
I forgot to include fixes for review comments I got before pushing the previous commits (or I pushed the wrong commits). This one fixes it. - Return {} instead of false in get_discrete_low_bound and get_discrete_high_bound. - Compute high bound after confirming low bound is valid in get_discrete_bounds. gdb/ChangeLog: * gdbtypes.c (get_discrete_low_bound, get_discrete_high_bound): Return {} instead of false. (get_discrete_bounds): Compute high bound only if low bound is valid. Change-Id: I5f9a66b3672adfac9441068c899ab113ab2c331a
2020-12-09gdb: fix value_subscript when array upper bound is not knownSimon Marchi7-11/+179
Since commit 7c6f27129631 ("gdb: make get_discrete_bounds check for non-constant range bounds"), subscripting flexible array member fails: struct no_size { int n; int items[]; }; (gdb) p *ns $1 = {n = 3, items = 0x5555555592a4} (gdb) p ns->items[0] Cannot access memory at address 0xfffe555b733a0164 (gdb) p *((int *) 0x5555555592a4) $2 = 101 <--- we would expect that (gdb) p &ns->items[0] $3 = (int *) 0xfffe5559ee829a24 <--- wrong address Since the flexible array member (items) has an unspecified size, the array type created for it in the DWARF doesn't have dimensions (this is with gcc 9.3.0, Ubuntu 20.04): 0x000000a4: DW_TAG_array_type DW_AT_type [DW_FORM_ref4] (0x00000038 "int") DW_AT_sibling [DW_FORM_ref4] (0x000000b3) 0x000000ad: DW_TAG_subrange_type DW_AT_type [DW_FORM_ref4] (0x00000031 "long unsigned int") This causes GDB to create a range type (TYPE_CODE_RANGE) with a defined constant low bound (dynamic_prop with kind PROP_CONST) and an undefined high bound (dynamic_prop with kind PROP_UNDEFINED). value_subscript gets both bounds of that range using get_discrete_bounds. Before commit 7c6f27129631, get_discrete_bounds didn't check the kind of the dynamic_props and would just blindly read them as if they were PROP_CONST. It would return 0 for the high bound, because we zero-initialize the range_bounds structure. And it didn't really matter in this case, because the returned high bound wasn't used in the end. Commit 7c6f27129631 changed get_discrete_bounds to return a failure if either the low or high bound is not a constant, to make sure we don't read a dynamic prop that isn't a PROP_CONST as a PROP_CONST. This change made get_discrete_bounds start to return a failure for that range, and as a result would not set *lowp and *highp. And since value_subscript doesn't check get_discrete_bounds' return value, it just carries on an uses an uninitialized value for the low bound. If value_subscript did check the return value of get_discrete_bounds, we would get an error message instead of a bogus value. But it would still be a bug, as we wouldn't be able to print the flexible array member's elements. Looking at value_subscript, we see that the low bound is always needed, but the high bound is only needed if !c_style. So, change value_subscript to use get_discrete_low_bound and get_discrete_high_bound separately. This fixes the case described above, where the low bound is known but the high bound isn't (and is not needed). This restores the original behavior without accessing a dynamic_prop in a wrong way. A test is added. In addition to the case described above, a case with an array member of size 0 is added, which is a GNU C extension that existed before flexible array members were introduced. That case currently fails when compiled with gcc <= 8. gcc <= 8 produces DWARF similar to the one shown above, while gcc 9 adds a DW_AT_count of 0 in there, which makes the high bound known. A case where an array member of size 0 is the only member of the struct is also added, as that was how PR 28675 was originally reported, and it's an interesting corner case that I think could trigger other funny bugs. Question about the implementation: in value_subscript, I made it such that if the low or high bound is unknown, we fall back to zero. That effectively makes it the same as it was before 7c6f27129631. But should we instead error() out? gdb/ChangeLog: PR 26875, PR 26901 * gdbtypes.c (get_discrete_low_bound): Make non-static. (get_discrete_high_bound): Make non-static. * gdbtypes.h (get_discrete_low_bound): New declaration. (get_discrete_high_bound): New declaration. * valarith.c (value_subscript): Only fetch high bound if necessary. gdb/testsuite/ChangeLog: PR 26875, PR 26901 * gdb.base/flexible-array-member.c: New test. * gdb.base/flexible-array-member.exp: New test. Change-Id: I832056f80e6c56f621f398b4780d55a3a1e299d7
2020-12-09gdb: split get_discrete_bounds in twoSimon Marchi2-57/+137
get_discrete_bounds is not flexible for ranges (TYPE_CODE_RANGE), in the sense that it returns true (success) only if both bounds are present and constant values. This is a problem for code that only needs to know the low bound and fails unnecessarily if the high bound is unknown. Split the function in two, get_discrete_low_bound and get_discrete_high_bound, that both return an optional. Provide a new implementation of get_discrete_bounds based on the two others, so the callers don't have to be changed. gdb/ChangeLog: * gdbtypes.c (get_discrete_bounds): Implement with get_discrete_low_bound and get_discrete_high_bound. (get_discrete_low_bound): New. (get_discrete_high_bound): New. Change-Id: I986b5e9c0dd969800e3fb9546af9c827d52e80d0
2020-12-09gdb: make get_discrete_bounds return boolSimon Marchi14-50/+58
get_discrete_bounds currently has three possible return values (see its current doc for details). It appears that for all callers, it would be sufficient to have a boolean "worked" / "didn't work" return value. Change the return type of get_discrete_bounds to bool and adjust all callers. Doing so simplifies the following patch. gdb/ChangeLog: * gdbtypes.h (get_discrete_bounds): Return bool, adjust all callers. * gdbtypes.c (get_discrete_bounds): Return bool. Change-Id: Ie51feee23c75f0cd7939742604282d745db59172
2020-12-09gdb: make discrete_position return optionalSimon Marchi4-25/+48
Instead of returning a boolean status and returning the value through a pointer, return an optional that does both jobs. This helps in the following patches, and I think it is an improvement in general. gdb/ChangeLog: * ada-lang.c (ada_value_slice_from_ptr): Adjust. (ada_value_slice): Adjust. (pos_atr): Adjust. * gdbtypes.c (get_discrete_bounds): Adjust. (discrete_position): Return optional. * gdbtypes.h (discrete_position): Return optional. Change-Id: I758dbd8858b296ee472ed39ec35db1dbd624a5ae
2020-12-08gas: Generate a new section for SHF_GNU_RETAINH.J. Lu7-21/+97
For .globl foo2 .section .data.foo,"aR" .align 4 .type foo2, @object .size foo2, 4 foo2: .long 2 .globl foo1 .section .data.foo .align 4 .type foo1, @object .size foo1, 4 foo1: .long 1 generate a new section if the SHF_GNU_RETAIN bit doesn't match. * config/obj-elf.c (SEC_ASSEMBLER_SHF_MASK): New. (get_section_by_match): Also check if SEC_ASSEMBLER_SHF_MASK of sh_flags matches. Rename info to sh_info. (obj_elf_change_section): Don't check previous SHF_GNU_RETAIN. Rename info to sh_info. (obj_elf_section): Rename info to sh_info. Set sh_flags for SHF_GNU_RETAIN. * config/obj-elf.h (elf_section_match): Rename info to sh_info. Add sh_flags. * testsuite/gas/elf/elf.exp: Run section27. * testsuite/gas/elf/section24b.d: Updated. * testsuite/gas/elf/section27.d: New file. * testsuite/gas/elf/section27.s: Likewise.
2020-12-09Automatic date update in version.inGDB Administrator1-1/+1
2020-12-08gdbsupport: Use LOCALAPPDATA to determine cache dirAlexander Fedotov2-0/+15
Use the LOCALAPPDATA environment variable to determine the cache dir when running on Windows with native command line, otherwise nasty warning "Couldn't determine a path for index cached directory" appears. Change-Id: I77903f9f0cb4743555866b8aea892cef55132589
2020-12-08[gdb/testsuite] Simplify gdb.arch/amd64-gs_base.expTom de Vries2-26/+7
Redo fix committed in commit 67748e0f66 "[gdb/testsuite] Make gdb.arch/amd64-gs_base.exp unsupported for i386" using is_amd64_regs_target. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-12-08 Tom de Vries <tdevries@suse.de> * gdb.arch/amd64-gs_base.exp: Undo commit 67748e0f66, reimplement using is_amd64_regs_target.
2020-12-08[gdb/testsuite] Fix gdb.ada/mi_task_arg.exp for -m32Tom de Vries2-2/+9
When running test-case gdb.ada/mi_task_arg.exp with target board unix/-m32, I run into: ... (gdb) ^M Expecting: ^(-stack-list-arguments 1[^M ]+)?(\^done,stack-args=\[ \ frame={level="0",args=\[\]}, \ frame={level="1",args=\[{name="<_task>",value="0x[0-9A-Fa-f]+"}\]}, \ frame={level="2",args=\[({name="self_id",value="0x[0-9A-Fa-f]+"})?\]},.*[^M ]+[(]gdb[)] ^M [ ]*) -stack-list-arguments 1^M ^done,stack-args=[ \ frame={level="0",args=[]}, \ frame={level="1",args=[{name="<_task>",value="0x808abf0"}]}, \ frame={level="2",args=[{name="self_id",value="<optimized out>"}]}, \ frame={level="3",args=[]},frame={level="4",args=[]}]^M (gdb) ^M FAIL: gdb.ada/mi_task_arg.exp: -stack-list-arguments 1 (unexpected output) ... The problem is that we're expecting a $hex for the value of self_id, but instead get <optimized out>. Looking at the debug info for self_id: ... <1><12a1f>: Abbrev Number: 84 (DW_TAG_subprogram) <12a20> DW_AT_name : system__tasking__stages__task_wrapper ... <2><12a35>: Abbrev Number: 61 (DW_TAG_formal_parameter) <12a36> DW_AT_name : self_id <12a40> DW_AT_location : 0x459e (location list) ... it refers to location information here: ... 0000459e 08053060 080531ac (DW_OP_fbreg: 0) 000045aa 0805327c 080532a5 (DW_OP_fbreg: 0) 000045b6 08053320 08053324 (DW_OP_fbreg: 0) ... while the pc used to retrieve the location information is 0x080531c5: ... $ gdb -batch outputs/gdb.ada/mi_task_arg/task_switch \ -ex "break 57" -ex run -ex bt ... #0 task_switch.break_me () at task_switch.adb:57 #1 0x0804aaae in task_switch.caller (<_task>=0x808abf0) \ at task_switch.adb:51 #2 0x080531c5 in system.tasking.stages.task_wrapper \ (self_id=<optimized out>) at s-tassta.adb:1295 ... which indeed falls outside of the ranges listed in the location info. Fix this by accepting <optimized out> as valid value of self_id. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-12-08 Tom de Vries <tdevries@suse.de> * gdb.ada/mi_task_arg.exp: Accept <optimized out> as valid value of self_id.
2020-12-08Automatic date update in version.inGDB Administrator1-1/+1
2020-12-07gdb.base/break-on-linker-gcd-function.exp: Remove unused variablePedro Alves2-1/+5
Commit: commit 4d142eaa28c64565b58fcdb5a83377ec9b778cb1 Author: Jan Kratochvil <jan.kratochvil@redhat.com> AuthorDate: Tue Jul 2 20:06:12 2013 +0000 gdb/testsuite/ * gdb.base/break-on-linker-gcd-function.exp: Replace prepare_for_testing by build_executable_from_specs and clean_restart. ... did: set additional_flags {-ffunction-sections -Wl,--gc-sections} -if {[prepare_for_testing $testfile.exp $testfile $srcfile \ - [list debug c++ additional_flags=$additional_flags]]} { +if {[build_executable_from_specs $testfile.exp $testfile \ + {c++ additional_flags=-Wl,--gc-sections} \ + $srcfile {debug c++ additional_flags=-ffunction-sections}]} { and that left the additional_flags variable behind. Remove it. gdb/testsuite/ChangeLog: * gdb.base/break-on-linker-gcd-function.exp: Remove unused 'additional_flags' variable.
2020-12-07Remove references to the unofficial SHF_GNU_BUILD_NOTE section flag.Nick Clifton4-6/+10
binutils * objcopy.c (is_mergeable_note_section): Remove reference to SHF_GNU_BUILD_NOTE. include * elf/common.h (SHF_GNU_BUILD_NOTE): Delete.
2020-12-07binutils: Make smart_rename safe tooSiddhesh Poyarekar6-42/+148
smart_rename is capable of handling symlinks by copying and it also tries to preserve ownership and permissions of files when they're overwritten during the rename. This is useful in objcopy where the file properties need to be preserved. However because smart_rename does this using file names, it leaves a race window between renames and permission fixes. This change removes this race window by using file descriptors from the original BFDs that were used to manipulate these files wherever possible. The file that is to be renamed is also passed as a file descriptor so that we use fchown/fchmod on the file descriptor, thus making sure that we only modify the file we have opened to write. Further, in case the file is to be overwritten (as is the case in ar or objcopy), the permissions that need to be restored are taken from the file descriptor that was opened for input so that integrity of the file status is maintained all the way through to the rename. binutils/ * rename.c * ar.c (write_archive) [!defined (_WIN32) || defined (__CYGWIN32__)]: Initialize TARGET_STAT and OFD to pass to SMART_RENAME. * arsup.c (ar_save) [defined (_WIN32) || defined (__CYGWIN32__)]: Likewise. * bucomm.h (smart_rename): Add new arguments to declaration. * objcopy.c (strip_main)[defined (_WIN32) || defined (__CYGWIN32__)]: Initialize COPYFD and pass to SMART_RENAME. (copy_main) [defined (_WIN32) || defined (__CYGWIN32__)]: Likewise. * rename.c (try_preserve_permissions): New function. (smart_rename): Use it and add new arguments.
2020-12-07objcopy: Get input file stat after BFD openSiddhesh Poyarekar2-16/+16
Get file state from the descriptor opened by copy_file for the input BFD. This ensures continuity in the view of the input file through the descriptor. At the moment it is only to preserve timestamps recorded at the point that we opened the file for input but in the next patch this state will also be used to preserve ownership and permissions wherever applicable. binutils/ * objcopy.c (copy_file): New argument IN_STAT. Return stat of ibfd through it. (strip_main): Remove redundant stat calls. adjust copy_file calls. (copy_main): Likewise.
2020-12-07binutils: Use file descriptors from make_tempnameSiddhesh Poyarekar8-14/+91
The purpose of creating a temporary file securely using mkstemp is defeated if it is closed in make_tempname and reopened later for use; it is as good as using mktemp. Get the file descriptor instead and then use it to create the BFD object. bfd/ * opncls.c (bfd_fdopenw): New function. * bfd-in2.h: Regenerate. binutils/ * bucomm.c (make_tempname): Add argument to return file descriptor. * bucomm.h (make_tempname): Likewise. * ar.c: Include libbfd.h. (write_archive): Adjust for change in make_tempname. Call bfd_fdopenw instead of bfd_openw. * objcopy.c: Include libbfd.h. (copy_file): New argument OFD. Use bfd_fdopenw instead of bfd_openw. (strip_main): Adjust for change in make_tempname and copy_file. (copy_main): Likewise.
2020-12-07Use expression completer for "maint print type"Tom Tromey2-1/+7
I happened to notice that expression completion did not work correctly for "maint print type". This patch adds the appropriate completer there. gdb/ChangeLog 2020-12-07 Tom Tromey <tromey@adacore.com> * maint.c (_initialize_maint_cmds): Use expression command completer for "maint print type".
2020-12-07[GOLD] gcc-11 stringop-overflow warningAlan Modra2-1/+5
I'm unsure why this is deserving of a warning. Not writing the most efficient code surely can't be a real problem, but that is what https://gcc.gnu.org/bugzilla//show_bug.cgi?id=88059#c1 seems to say. plugin.cc:528:10: error: 'char* strncpy(char*, const char*, size_t)' specified bound depends on the length of the source argument [-Werror=stringop-overflow=] 528 | strncpy(tempdir, dir_template, len); | ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~ plugin.cc:526:22: note: length computed here 526 | size_t len = strlen(dir_template) + 1; | ~~~~~~^~~~~~~~~~~~~~ * plugin.cc (Plugin_recorder::init): Replace strncpy with memcpy.
2020-12-07elf32-csky.c:3932:19: error: comparison is always falseAlan Modra4-9/+9
It looks like csky missed out on an edit for 706704c8834. Not that it matters very much. There doesn't appear to be any csky reloc howto that sets the negate bit. Similarly for ns32k and nds32. * elf32-csky.c (csky_relocate_contents): Correct negate test. * cpu-ns32k.c (_bfd_do_ns32k_reloc_contents): Likewise. * elf32-nds32.c (nds32_relocate_contents): Likewise.
2020-12-07README-how-to-make-a-release (point releases): Add a note to update the ↵Nick Clifton2-8/+21
milestone list on sourceware's bugzilla.
2020-12-07gdb/completer: improve tab completion to consider the '-force-condition' flagTankut Baris Aktemur4-1/+29
The commit commit 733d554a4625db4ffb89b7a20e1cf27ab071ef4d Author: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> Date: Tue Oct 27 10:56:03 2020 +0100 gdb/breakpoint: add flags to 'condition' and 'break' commands to force condition introduced the '-force-condition' flag to the 'break' command. This flag was defined as a keyword like 'thread', 'task', and 'if'. However, it starts with '-'. This difference caused an uncovered case when tab-completing a seemingly complete linespec. Below, we see "-force-condition" in the completion list, where both the options and the keywords are listed: (gdb) break -function main <TAB> -force-condition -function -label -line -qualified -source if task thread But tab-completing '-' lists only options: (gdb) break -function main -<TAB> -function -label -line -qualified -source This patch fixes the problem by adding keywords to the completion list, so that we see: (gdb) break -function main -<TAB> -force-condition -function -label -line -qualified -source gdb/ChangeLog: 2020-12-07 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * completer.c (complete_explicit_location): Also add keywords that start with '-' to the completion list. gdb/testsuite/ChangeLog: 2020-12-07 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * gdb.linespec/explicit.exp: Extend with a test to check completing '-' after seemingly complete options.
2020-12-07gdb/linespec: relax the position of the '-force-condition' flagTankut Baris Aktemur5-17/+54
The break command's "-force-condition" flag is currently required to be followed by the "if" keyword. This prevents flexibility when using other keywords, e.g. "thread": (gdb) break main -force-condition thread 1 if foo Function "main -force-condition" not defined. Make breakpoint pending on future shared library load? (y or [n]) n Remove the requirement that "-force-condition" is always followed by an "if", so that more flexibility is obtained when positioning keywords. gdb/ChangeLog: 2020-12-07 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * linespec.c (linespec_lexer_lex_keyword): The "-force-condition" keyword may be followed by any keyword. * breakpoint.c (find_condition_and_thread): Advance 'tok' by 'toklen' in the case for "-force-condition". gdb/testsuite/ChangeLog: 2020-12-07 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * gdb.linespec/keywords.exp: Add tests to check positional flexibility of "-force-condition".
2020-12-07gdb/main: execute breakpoint commands for '-iex' and '-ex' commandsTankut Baris Aktemur8-4/+114
Suppose we have the script file below: break main commands print 123 end run If started with this script file, GDB executes the breakpoint command: $ gdb -q -x myscript --args ./test Reading symbols from ./test... Breakpoint 1 at 0x114e: file test.c, line 2. Breakpoint 1, main () at test.c:2 2 return 0; $1 = 123 (gdb) However, if we remove the "run" line from the script and pass it with the '-ex' option instead, the command is not executed: $ gdb -q -x myscript_no_run --args ./test Reading symbols from ./test... Breakpoint 1 at 0x114e: file test.c, line 2. Starting program: /path/to/test Breakpoint 1, main () at test.c:2 2 return 0; (gdb) If the user enters a command at this point, the breakpoint command is executed, yielding weird output: $ gdb -q -x myscript_no_run --args ./test Reading symbols from ./test... Breakpoint 1 at 0x114e: file test.c, line 2. Starting program: /path/to/test Breakpoint 1, main () at test.c:2 2 return 0; (gdb) print "a" $1 = "a" $2 = 123 When consuming script files, GDB runs bp actions after executing a command. See `command_handler` in event-top.c: if (c[0] != '#') { execute_command (command, ui->instream == ui->stdin_stream); /* Do any commands attached to breakpoint we stopped at. */ bpstat_do_actions (); } However, for '-ex' commands, `bpstat_do_actions` is not invoked. Hence, the misaligned output explained above occurs. To fix the problem, add a call to `bpstat_do_actions` after executing a command. gdb/ChangeLog: 2020-12-07 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * main.c (catch_command_errors): Add a flag parameter; invoke `bpstat_do_actions` if the flag is set. (execute_cmdargs): Update a call to `catch_command_errors`. gdb/testsuite/ChangeLog: 2020-12-07 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * gdb.base/bp-cmds-run-with-ex.c: New file. * gdb.base/bp-cmds-run-with-ex.exp: New file. * gdb.base/bp-cmds-run-with-ex.gdb: New file. * gdb.gdb/python-interrupts.exp: Update the call to 'catch_command_errors' with the new argument. * gdb.gdb/python-selftest.exp: Ditto.
2020-12-07[gdb/ada] Handle shrink resize in replace_operator_with_callTom de Vries2-2/+10
In replace_operator_with_call, we resize the elts array like this: ... exp->nelts = exp->nelts + 7 - oplen; exp->resize (exp->nelts); ... Although all the current callers ensure that the new size is bigger, it could also be smaller, in which case the following memmove possibly reads out of bounds: ... memmove (exp->elts + pc + 7, exp->elts + pc + oplen, EXP_ELEM_TO_BYTES (save_nelts - pc - oplen)); ... Fix this by doing the resize after the memmove in case the new size is smaller. Tested on x86_64-linux. gdb/ChangeLog: 2020-12-07 Tom de Vries <tdevries@suse.de> * ada-lang.c (replace_operator_with_call): Handle shrink resize.
2020-12-06Fix struct expression regressionTom Tromey2-18/+18
The patch to change struct expression to use new introduced a regression -- there is a spot that reallocates expressions that I failed to update. This patch rewrites this code to follow the new approach. Now the rewriting is done in place. gdb/ChangeLog 2020-12-06 Tom Tromey <tom@tromey.com> PR ada/26999 * ada-lang.c (replace_operator_with_call): Rewrite.
2020-12-07Automatic date update in version.inGDB Administrator1-1/+1
2020-12-06s390: Fix BC instruction breakpoint handlingGiancarlo Frix2-1/+6
This fixes a long-lived bug in the s390 port. When trying to step over a breakpoint set on a BC (branch on condition) instruction with displaced stepping on IBM Z, gdb would incorrectly adjust the pc regardless of whether or not the branch was taken. Since the branch target is an absolute address, this would cause the inferior to jump around wildly whenever the branch was taken, either crashing it or causing it to behave unpredictably. It turns out that the logic to handle BC instructions correctly was in the code, but that the enum value representing its opcode has always been incorrect. This patch corrects the enum value to the actual opcode, fixing the stepping problem. The enum value is also used in the prologue analysis code, so this also fixes a minor bug where more of the prologue would be read than was necessary. gdb/ChangeLog: PR breakpoints/27009 * s390-tdep.h (op_bc): Correct BC opcode value.
2020-12-05gmp-utils: protect gdb_mpz exports against out-of-range valuesJoel Brobecker4-29/+174
The gdb_mpz class currently provides a couple of methods which essentially export an mpz_t value into either a buffer, or an integral type. The export is based on using the mpz_export function which we discovered can be a bit treacherous if used without caution. In particular, the initial motivation for this patch was to catch situations where the mpz_t value was so large that it would not fit in the destination area. mpz_export does not know the size of the buffer, and therefore can happily write past the end of our buffer. While designing a solution to the above problem, I also discovered that we also needed to be careful when exporting signed numbers. In particular, numbers which are larger than the maximum value for a given signed type size, but no so large as to fit in the *unsigned* version with the same size, would end up being exported incorrectly. This is related to the fact that mpz_export ignores the sign of the value being exportd, and assumes an unsigned export. Thus, for such large values, the appears as if mpz_export is able to fit our value into our buffer, but in fact, it does not. Also, I noticed that gdb_mpz::write wasn't taking its unsigned_p parameter, which was a hole. For all these reasons, a new low-level private method called "safe_export" has been added to class gdb_mpz, whose goal is to perform all necessary checks and manipulations for a safe and correct export. As a bonus, this method allows us to factorize the handling of negative value exports. The gdb_mpz::as_integer and gdb_mpz::write methods are then simplified to take advantage of this new safe_export method. gdb/ChangeLog: * gmp-utils.h (gdb_mpz::safe_export): New private method. (gdb_mpz::as_integer): Reimplement using gdb_mpz::safe_export. * gmp-utils.c (gdb_mpz::write): Rewrite using gdb_mpz::safe_export. (gdb_mpz::safe_export): New method. * unittests/gmp-utils-selftests .c (gdb_mpz_as_integer): Update function description. (check_as_integer_raises_out_of_range_error): New function. (gdb_mpz_as_integer_out_of_range): New function. (_initialize_gmp_utils_selftests): Register gdb_mpz_as_integer_out_of_range as a selftest.
2020-12-06Automatic date update in version.inGDB Administrator1-1/+1
2020-12-05VAX/BFD: Do not warn about GOT addend mismatches if no GOT entry is madeMaciej W. Rozycki17-3/+245
Match the condition used in `elf_vax_instantiate_got_entries' for the creation of GOT entries in the processing of R_VAX_GOT32 relocations in `elf_vax_check_relocs', removing incorrect warnings about a GOT addend mismatch like: ./ld-new: tmpdir/got-local-ref-off-r.o: warning: GOT addend of 1 to `bar_hidden' does not match previous GOT addend of 0 ./ld-new: tmpdir/got-local-ref-off-r.o: warning: GOT addend of 2 to `bar_hidden' does not match previous GOT addend of 0 and corresponding failures with the test cases newly added here: FAIL: GOT test (executable hidden reference with offset) FAIL: GOT test (executable visible reference with offset) for symbols that are considered local for reasons other than having been forced local with a version script, which is usually the ELF visibility. Correct code is produced regardless, but the warning breaks `-Werror' compilation and may upset people regardless. Interestingly this shows with executable links only, because in shared library links code from `elf_link_add_object_symbols' triggers: /* If the symbol already has a dynamic index, but visibility says it should not be visible, turn it into a local symbol. */ switch (ELF_ST_VISIBILITY (h->other)) { case STV_INTERNAL: case STV_HIDDEN: (*bed->elf_backend_hide_symbol) (info, h, TRUE); dynsym = FALSE; break; } that sets `h->forced_local' like with a version script. Add suitable test cases including disassembly to verify correct code has been produced where no warnings have been issued, and that warnings do get issued where necessary. Do not verify (broken) code produced in the latter case; we should probably make the warning an error, or preferably actually start supporting GOT references with different addends as they appear feasible with explicitly relocated GOT that we use. bfd/ * elf32-vax.c (elf_vax_check_relocs) <R_VAX_GOT32>: Use SYMBOL_REFERENCES_LOCAL rather than `h->forced_local' to check whether the symbol referred is local or not. ld/ * testsuite/ld-vax-elf/got-local-exe-off-hidden.dd: New test dump. * testsuite/ld-vax-elf/got-local-exe-off-visible.dd: New test dump. * testsuite/ld-vax-elf/got-local-lib-off-hidden.dd: New test dump. * testsuite/ld-vax-elf/got-local-lib-off-visible.ed: New test dump. * testsuite/ld-vax-elf/got-local-off-external.ed: New test dump. * testsuite/ld-vax-elf/got-local-exe-off.xd: New test dump. * testsuite/ld-vax-elf/got-local-lib-off.xd: New test dump. * testsuite/ld-vax-elf/got-local.ld: New test linker script. * testsuite/ld-vax-elf/got-local-aux-off.s: New test source. * testsuite/ld-vax-elf/got-local-def-off.s: New test source. * testsuite/ld-vax-elf/got-local-ref-off-external.s: New test source. * testsuite/ld-vax-elf/got-local-ref-off-hidden.s: New test source. * testsuite/ld-vax-elf/got-local-ref-off-visible.s: New test source. * testsuite/ld-vax-elf/vax-elf.exp: Run the new tests.
2020-12-05Fix TARGET_CHAR_BIT/HOST_CHAR_BIT confusion in gmp-utils.cJoel Brobecker2-2/+8
In a couple of gdb_mpz methods, we are computing the number of bits in a gdb::array_view of gdb_byte. Since gdb_byte is defined using a host-side type (see common-types.h), the number of bits in a gdb_byte should be HOST_CHAR_BIT, not TARGET_CHAR_BIT. gdb/ChangeLog: * gmp-utils.c (gdb_mpz::read): Use HOST_CHAR_BIT instead of TARGET_CHAR_BIT. (gdb_mpz::write): Likewise.
2020-12-04x86-64: Convert load to mov only for GOTPCRELX relocationsH.J. Lu8-1/+91
Since converting load to mov needs to rewrite the REX byte and we don't know if there is a REX byte with GOTPCREL relocation, do it only for GOTPCRELX relocations. bfd/ PR ld/27016 * elf64-x86-64.c (elf_x86_64_convert_load_reloc): Convert load to mov only for GOTPCRELX relocations. ld/ PR ld/27016 * testsuite/ld-x86-64/x86-64.exp: Run pr27016a and pr27016b. * testsuite/ld-x86-64/pr27016a.d: New file. * testsuite/ld-x86-64/pr27016a.s: Likewise. * testsuite/ld-x86-64/pr27016b.d: Likewise. * testsuite/ld-x86-64/pr27016b.s: Likewise.
2020-12-05Automatic date update in version.inGDB Administrator1-1/+1
2020-12-04gdb: use two displaced step buffers on amd64/LinuxSimon Marchi2-1/+6
As observed on a binary compiled on AMD64 Ubuntu 20.04, against glibc 2.31 (I think it's the libc that provides this startup code, right?), there are enough bytes at the executable's entry point to hold more than one displaced step buffer. gdbarch_max_insn_length is 16, and the code at _start looks like: 0000000000001040 <_start>: 1040: f3 0f 1e fa endbr64 1044: 31 ed xor %ebp,%ebp 1046: 49 89 d1 mov %rdx,%r9 1049: 5e pop %rsi 104a: 48 89 e2 mov %rsp,%rdx 104d: 48 83 e4 f0 and $0xfffffffffffffff0,%rsp 1051: 50 push %rax 1052: 54 push %rsp 1053: 4c 8d 05 56 01 00 00 lea 0x156(%rip),%r8 # 11b0 <__libc_csu_fini> 105a: 48 8d 0d df 00 00 00 lea 0xdf(%rip),%rcx # 1140 <__libc_csu_init> 1061: 48 8d 3d c1 00 00 00 lea 0xc1(%rip),%rdi # 1129 <main> 1068: ff 15 72 2f 00 00 callq *0x2f72(%rip) # 3fe0 <__libc_start_main@GLIBC_2.2.5> 106e: f4 hlt 106f: 90 nop The two buffers would occupy [0x1040, 0x1060). I checked on Alpine, which uses the musl C library, the startup code looks like: 0000000000001048 <_start>: 1048: 48 31 ed xor %rbp,%rbp 104b: 48 89 e7 mov %rsp,%rdi 104e: 48 8d 35 e3 2d 00 00 lea 0x2de3(%rip),%rsi # 3e38 <_DYNAMIC> 1055: 48 83 e4 f0 and $0xfffffffffffffff0,%rsp 1059: e8 00 00 00 00 callq 105e <_start_c> 000000000000105e <_start_c>: 105e: 48 8b 37 mov (%rdi),%rsi 1061: 48 8d 57 08 lea 0x8(%rdi),%rdx 1065: 45 31 c9 xor %r9d,%r9d 1068: 4c 8d 05 47 01 00 00 lea 0x147(%rip),%r8 # 11b6 <_fini> 106f: 48 8d 0d 8a ff ff ff lea -0x76(%rip),%rcx # 1000 <_init> 1076: 48 8d 3d 0c 01 00 00 lea 0x10c(%rip),%rdi # 1189 <main> 107d: e9 9e ff ff ff jmpq 1020 <__libc_start_main@plt> Even though there's a _start_c symbol, it all appears to be code that runs once at the very beginning of the program, so it looks fine if the two buffers occupy [0x1048, 0x1068). One important thing I discovered while doing this is that when debugging a dynamically-linked executable, breakpoints in the shared library loader are hit before executing the _start code, and these breakpoints may be displaced-stepped. So it's very important that the buffer bytes are restored properly after doing the displaced steps, otherwise the _start code will be corrupted once we try to execute it. Another thing that made me think about is that library constructors (as in `__attribute__((constructor))`) run before _start. And they are free to spawn threads. What if one of these threads executes a displaced step, therefore changing the bytes at _start, while the main thread executes _start? That doesn't sound good and I don't know how we could prevent it. But this is a problem that predates the current patch. Even when stress-testing the implementation, by making many threads do displaced steps over and over, I didn't see a significant performance (I confirmed that the two buffers were used by checking the "set debug displaced" logs though). However, this patch mostly helps make the feature testable by anybody with an AMD64/Linux machine, so I think it's useful. gdb/ChangeLog: * amd64-linux-tdep.c (amd64_linux_init_abi): Pass 2 as the number of displaced step buffers. Change-Id: Ia0c96ea0fcda893f4726df6fdac7be5214620112
2020-12-04gdb: make displaced stepping implementation capable of managing multiple buffersSimon Marchi34-126/+295
The displaced_step_buffer class, introduced in the previous patch, manages access to a single displaced step buffer. Change it into displaced_step_buffers (note the plural), which manages access to multiple displaced step buffers. When preparing a displaced step for a thread, it looks for an unused buffer. For now, all users still pass a single displaced step buffer, so no real behavior change is expected here. The following patch makes a user pass more than one buffer, so the functionality introduced by this patch is going to be useful in the next one. gdb/ChangeLog: * displaced-stepping.h (struct displaced_step_buffer): Rename to... (struct displaced_step_buffers): ... this. <m_addr, m_current_thread, m_copy_insn_closure>: Remove. <struct displaced_step_buffer>: New inner class. <m_buffers>: New. * displaced-stepping.c (displaced_step_buffer::prepare): Rename to... (displaced_step_buffers::prepare): ... this, adjust for multiple buffers. (displaced_step_buffer::finish): Rename to... (displaced_step_buffers::finish): ... this, adjust for multiple buffers. (displaced_step_buffer::copy_insn_closure_by_addr): Rename to... (displaced_step_buffers::copy_insn_closure_by_addr): ... this, adjust for multiple buffers. (displaced_step_buffer::restore_in_ptid): Rename to... (displaced_step_buffers::restore_in_ptid): ... this, adjust for multiple buffers. * linux-tdep.h (linux_init_abi): Change supports_displaced_step for num_disp_step_buffers. * linux-tdep.c (struct linux_gdbarch_data) <num_disp_step_buffers>: New field. (struct linux_info) <disp_step_buf>: Rename to... <disp_step_bufs>: ... this, change type to displaced_step_buffers. (linux_displaced_step_prepare): Use linux_gdbarch_data::num_disp_step_buffers to create that number of buffers. (linux_displaced_step_finish): Adjust. (linux_displaced_step_copy_insn_closure_by_addr): Adjust. (linux_displaced_step_restore_all_in_ptid): Adjust. (linux_init_abi): Change supports_displaced_step parameter for num_disp_step_buffers, save it in linux_gdbarch_data. * aarch64-linux-tdep.c (aarch64_linux_init_abi): Adjust. * alpha-linux-tdep.c (alpha_linux_init_abi): Adjust. * amd64-linux-tdep.c (amd64_linux_init_abi_common): Change supports_displaced_step parameter for num_disp_step_buffers. (amd64_linux_init_abi): Adjust. (amd64_x32_linux_init_abi): Adjust. * arc-linux-tdep.c (arc_linux_init_osabi): Adjust. * arm-linux-tdep.c (arm_linux_init_abi): Adjust. * bfin-linux-tdep.c (bfin_linux_init_abi): Adjust. * cris-linux-tdep.c (cris_linux_init_abi): Adjust. * csky-linux-tdep.c (csky_linux_init_abi): Adjust. * frv-linux-tdep.c (frv_linux_init_abi): Adjust. * hppa-linux-tdep.c (hppa_linux_init_abi): Adjust. * i386-linux-tdep.c (i386_linux_init_abi): Adjust. * ia64-linux-tdep.c (ia64_linux_init_abi): Adjust. * m32r-linux-tdep.c (m32r_linux_init_abi): Adjust. * m68k-linux-tdep.c (m68k_linux_init_abi): * microblaze-linux-tdep.c (microblaze_linux_init_abi): * mips-linux-tdep.c (mips_linux_init_abi): Adjust. * mn10300-linux-tdep.c (am33_linux_init_osabi): Adjust. * nios2-linux-tdep.c (nios2_linux_init_abi): Adjust. * or1k-linux-tdep.c (or1k_linux_init_abi): Adjust. * ppc-linux-tdep.c (ppc_linux_init_abi): Adjust. * riscv-linux-tdep.c (riscv_linux_init_abi): Adjust. * rs6000-tdep.c (struct ppc_inferior_data) <disp_step_buf>: Change type to displaced_step_buffers. * s390-linux-tdep.c (s390_linux_init_abi_any): Adjust. * sh-linux-tdep.c (sh_linux_init_abi): Adjust. * sparc-linux-tdep.c (sparc32_linux_init_abi): Adjust. * sparc64-linux-tdep.c (sparc64_linux_init_abi): Adjust. * tic6x-linux-tdep.c (tic6x_uclinux_init_abi): Adjust. * tilegx-linux-tdep.c (tilegx_linux_init_abi): Adjust. * xtensa-linux-tdep.c (xtensa_linux_init_abi): Adjust. Change-Id: Ia9c02f207da2c9e1d9188020139619122392bb70
2020-12-04gdb: change linux gdbarch data from post to pre-initSimon Marchi2-3/+10
The following patch will need to fill a field in linux_gdbarch_data while the gdbarch is being built. linux_gdbarch_data is currently allocated as a post-init gdbarch data, meaning it's not possible to fill it before the gdbarch is completely initialized. Change it to a pre-init gdbarch data to allow this. The init_linux_gdbarch_data function doesn't use the created gdbarch, it only allocates the linux_gdbarch_data structure on the gdbarch's obstack, so the change is trivial. gdb/ChangeLog: * linux-tdep.c (init_linux_gdbarch_data): Change parameter to obkstack. (_initialize_linux_tdep): Register pre-init gdb data instead of post-init. Change-Id: If35ce91b6bb5435680d43b9268d811d95661644f
2020-12-04gdb: move displaced stepping logic to gdbarch, allow starting concurrent ↵Simon Marchi48-307/+1010
displaced steps Today, GDB only allows a single displaced stepping operation to happen per inferior at a time. There is a single displaced stepping buffer per inferior, whose address is fixed (obtained with gdbarch_displaced_step_location), managed by infrun.c. In the case of the AMD ROCm target [1] (in the context of which this work has been done), it is typical to have thousands of threads (or waves, in SMT terminology) executing the same code, hitting the same breakpoint (possibly conditional) and needing to to displaced step it at the same time. The limitation of only one displaced step executing at a any given time becomes a real bottleneck. To fix this bottleneck, we want to make it possible for threads of a same inferior to execute multiple displaced steps in parallel. This patch builds the foundation for that. In essence, this patch moves the task of preparing a displaced step and cleaning up after to gdbarch functions. This allows using different schemes for allocating and managing displaced stepping buffers for different platforms. The gdbarch decides how to assign a buffer to a thread that needs to execute a displaced step. On the ROCm target, we are able to allocate one displaced stepping buffer per thread, so a thread will never have to wait to execute a displaced step. On Linux, the entry point of the executable if used as the displaced stepping buffer, since we assume that this code won't get used after startup. From what I saw (I checked with a binary generated against glibc and musl), on AMD64 we have enough space there to fit two displaced stepping buffers. A subsequent patch makes AMD64/Linux use two buffers. In addition to having multiple displaced stepping buffers, there is also the idea of sharing displaced stepping buffers between threads. Two threads doing displaced steps for the same PC could use the same buffer at the same time. Two threads stepping over the same instruction (same opcode) at two different PCs may also be able to share a displaced stepping buffer. This is an idea for future patches, but the architecture built by this patch is made to allow this. Now, the implementation details. The main part of this patch is moving the responsibility of preparing and finishing a displaced step to the gdbarch. Before this patch, preparing a displaced step is driven by the displaced_step_prepare_throw function. It does some calls to the gdbarch to do some low-level operations, but the high-level logic is there. The steps are roughly: - Ask the gdbarch for the displaced step buffer location - Save the existing bytes in the displaced step buffer - Ask the gdbarch to copy the instruction into the displaced step buffer - Set the pc of the thread to the beginning of the displaced step buffer Similarly, the "fixup" phase, executed after the instruction was successfully single-stepped, is driven by the infrun code (function displaced_step_finish). The steps are roughly: - Restore the original bytes in the displaced stepping buffer - Ask the gdbarch to fixup the instruction result (adjust the target's registers or memory to do as if the instruction had been executed in its original location) The displaced_step_inferior_state::step_thread field indicates which thread (if any) is currently using the displaced stepping buffer, so it is used by displaced_step_prepare_throw to check if the displaced stepping buffer is free to use or not. This patch defers the whole task of preparing and cleaning up after a displaced step to the gdbarch. Two new main gdbarch methods are added, with the following semantics: - gdbarch_displaced_step_prepare: Prepare for the given thread to execute a displaced step of the instruction located at its current PC. Upon return, everything should be ready for GDB to resume the thread (with either a single step or continue, as indicated by gdbarch_displaced_step_hw_singlestep) to make it displaced step the instruction. - gdbarch_displaced_step_finish: Called when the thread stopped after having started a displaced step. Verify if the instruction was executed, if so apply any fixup required to compensate for the fact that the instruction was executed at a different place than its original pc. Release any resources that were allocated for this displaced step. Upon return, everything should be ready for GDB to resume the thread in its "normal" code path. The displaced_step_prepare_throw function now pretty much just offloads to gdbarch_displaced_step_prepare and the displaced_step_finish function offloads to gdbarch_displaced_step_finish. The gdbarch_displaced_step_location method is now unnecessary, so is removed. Indeed, the core of GDB doesn't know how many displaced step buffers there are nor where they are. To keep the existing behavior for existing architectures, the logic that was previously implemented in infrun.c for preparing and finishing a displaced step is moved to displaced-stepping.c, to the displaced_step_buffer class. Architectures are modified to implement the new gdbarch methods using this class. The behavior is not expected to change. The other important change (which arises from the above) is that the core of GDB no longer prevents concurrent displaced steps. Before this patch, start_step_over walks the global step over chain and tries to initiate a step over (whether it is in-line or displaced). It follows these rules: - if an in-line step is in progress (in any inferior), don't start any other step over - if a displaced step is in progress for an inferior, don't start another displaced step for that inferior After starting a displaced step for a given inferior, it won't start another displaced step for that inferior. In the new code, start_step_over simply tries to initiate step overs for all the threads in the list. But because threads may be added back to the global list as it iterates the global list, trying to initiate step overs, start_step_over now starts by stealing the global queue into a local queue and iterates on the local queue. In the typical case, each thread will either: - have initiated a displaced step and be resumed - have been added back by the global step over queue by displaced_step_prepare_throw, because the gdbarch will have returned that there aren't enough resources (i.e. buffers) to initiate a displaced step for that thread Lastly, if start_step_over initiates an in-line step, it stops iterating, and moves back whatever remaining threads it had in its local step over queue to the global step over queue. Two other gdbarch methods are added, to handle some slightly annoying corner cases. They feel awkwardly specific to these cases, but I don't see any way around them: - gdbarch_displaced_step_copy_insn_closure_by_addr: in arm_pc_is_thumb, arm-tdep.c wants to get the closure for a given buffer address. - gdbarch_displaced_step_restore_all_in_ptid: when a process forks (at least on Linux), the address space is copied. If some displaced step buffers were in use at the time of the fork, we need to restore the original bytes in the child's address space. These two adjustments are also made in infrun.c: - prepare_for_detach: there may be multiple threads doing displaced steps when we detach, so wait until all of them are done - handle_inferior_event: when we handle a fork event for a given thread, it's possible that other threads are doing a displaced step at the same time. Make sure to restore the displaced step buffer contents in the child for them. [1] https://github.com/ROCm-Developer-Tools/ROCgdb gdb/ChangeLog: * displaced-stepping.h (struct displaced_step_copy_insn_closure): Adjust comments. (struct displaced_step_inferior_state) <step_thread, step_gdbarch, step_closure, step_original, step_copy, step_saved_copy>: Remove fields. (struct displaced_step_thread_state): New. (struct displaced_step_buffer): New. * displaced-stepping.c (displaced_step_buffer::prepare): New. (write_memory_ptid): Move from infrun.c. (displaced_step_instruction_executed_successfully): New, factored out of displaced_step_finish. (displaced_step_buffer::finish): New. (displaced_step_buffer::copy_insn_closure_by_addr): New. (displaced_step_buffer::restore_in_ptid): New. * gdbarch.sh (displaced_step_location): Remove. (displaced_step_prepare, displaced_step_finish, displaced_step_copy_insn_closure_by_addr, displaced_step_restore_all_in_ptid): New. * gdbarch.c: Re-generate. * gdbarch.h: Re-generate. * gdbthread.h (class thread_info) <displaced_step_state>: New field. (thread_step_over_chain_remove): New declaration. (thread_step_over_chain_next): New declaration. (thread_step_over_chain_length): New declaration. * thread.c (thread_step_over_chain_remove): Make non-static. (thread_step_over_chain_next): New. (global_thread_step_over_chain_next): Use thread_step_over_chain_next. (thread_step_over_chain_length): New. (global_thread_step_over_chain_enqueue): Add debug print. (global_thread_step_over_chain_remove): Add debug print. * infrun.h (get_displaced_step_copy_insn_closure_by_addr): Remove. * infrun.c (get_displaced_stepping_state): New. (displaced_step_in_progress_any_inferior): Remove. (displaced_step_in_progress_thread): Adjust. (displaced_step_in_progress): Adjust. (displaced_step_in_progress_any_thread): New. (get_displaced_step_copy_insn_closure_by_addr): Remove. (gdbarch_supports_displaced_stepping): Use gdbarch_displaced_step_prepare_p. (displaced_step_reset): Change parameter from inferior to thread. (displaced_step_prepare_throw): Implement using gdbarch_displaced_step_prepare. (write_memory_ptid): Move to displaced-step.c. (displaced_step_restore): Remove. (displaced_step_finish): Implement using gdbarch_displaced_step_finish. (start_step_over): Allow starting more than one displaced step. (prepare_for_detach): Handle possibly multiple threads doing displaced steps. (handle_inferior_event): Handle possibility that fork event happens while another thread displaced steps. * linux-tdep.h (linux_displaced_step_prepare): New. (linux_displaced_step_finish): New. (linux_displaced_step_copy_insn_closure_by_addr): New. (linux_displaced_step_restore_all_in_ptid): New. (linux_init_abi): Add supports_displaced_step parameter. * linux-tdep.c (struct linux_info) <disp_step_buf>: New field. (linux_displaced_step_prepare): New. (linux_displaced_step_finish): New. (linux_displaced_step_copy_insn_closure_by_addr): New. (linux_displaced_step_restore_all_in_ptid): New. (linux_init_abi): Add supports_displaced_step parameter, register displaced step methods if true. (_initialize_linux_tdep): Register inferior_execd observer. * amd64-linux-tdep.c (amd64_linux_init_abi_common): Add supports_displaced_step parameter, adjust call to linux_init_abi. Remove call to set_gdbarch_displaced_step_location. (amd64_linux_init_abi): Adjust call to amd64_linux_init_abi_common. (amd64_x32_linux_init_abi): Likewise. * aarch64-linux-tdep.c (aarch64_linux_init_abi): Adjust call to linux_init_abi. Remove call to set_gdbarch_displaced_step_location. * arm-linux-tdep.c (arm_linux_init_abi): Likewise. * i386-linux-tdep.c (i386_linux_init_abi): Likewise. * alpha-linux-tdep.c (alpha_linux_init_abi): Adjust call to linux_init_abi. * arc-linux-tdep.c (arc_linux_init_osabi): Likewise. * bfin-linux-tdep.c (bfin_linux_init_abi): Likewise. * cris-linux-tdep.c (cris_linux_init_abi): Likewise. * csky-linux-tdep.c (csky_linux_init_abi): Likewise. * frv-linux-tdep.c (frv_linux_init_abi): Likewise. * hppa-linux-tdep.c (hppa_linux_init_abi): Likewise. * ia64-linux-tdep.c (ia64_linux_init_abi): Likewise. * m32r-linux-tdep.c (m32r_linux_init_abi): Likewise. * m68k-linux-tdep.c (m68k_linux_init_abi): Likewise. * microblaze-linux-tdep.c (microblaze_linux_init_abi): Likewise. * mips-linux-tdep.c (mips_linux_init_abi): Likewise. * mn10300-linux-tdep.c (am33_linux_init_osabi): Likewise. * nios2-linux-tdep.c (nios2_linux_init_abi): Likewise. * or1k-linux-tdep.c (or1k_linux_init_abi): Likewise. * riscv-linux-tdep.c (riscv_linux_init_abi): Likewise. * s390-linux-tdep.c (s390_linux_init_abi_any): Likewise. * sh-linux-tdep.c (sh_linux_init_abi): Likewise. * sparc-linux-tdep.c (sparc32_linux_init_abi): Likewise. * sparc64-linux-tdep.c (sparc64_linux_init_abi): Likewise. * tic6x-linux-tdep.c (tic6x_uclinux_init_abi): Likewise. * tilegx-linux-tdep.c (tilegx_linux_init_abi): Likewise. * xtensa-linux-tdep.c (xtensa_linux_init_abi): Likewise. * ppc-linux-tdep.c (ppc_linux_init_abi): Adjust call to linux_init_abi. Remove call to set_gdbarch_displaced_step_location. * arm-tdep.c (arm_pc_is_thumb): Call gdbarch_displaced_step_copy_insn_closure_by_addr instead of get_displaced_step_copy_insn_closure_by_addr. * rs6000-aix-tdep.c (rs6000_aix_init_osabi): Adjust calls to clear gdbarch methods. * rs6000-tdep.c (struct ppc_inferior_data): New structure. (get_ppc_per_inferior): New function. (ppc_displaced_step_prepare): New function. (ppc_displaced_step_finish): New function. (ppc_displaced_step_restore_all_in_ptid): New function. (rs6000_gdbarch_init): Register new gdbarch methods. * s390-tdep.c (s390_gdbarch_init): Don't call set_gdbarch_displaced_step_location, set new gdbarch methods. gdb/testsuite/ChangeLog: * gdb.arch/amd64-disp-step-avx.exp: Adjust pattern. * gdb.threads/forking-threads-plus-breakpoint.exp: Likewise. * gdb.threads/non-stop-fair-events.exp: Likewise. Change-Id: I387cd235a442d0620ec43608fd3dc0097fcbf8c8
2020-12-04gdb: move displaced stepping types to displaced-stepping.{h,c}Simon Marchi10-100/+170
Move displaced-stepping related stuff unchanged to displaced-stepping.h and displaced-stepping.c. This helps make the following patch a bit smaller and easier to read. gdb/ChangeLog: * Makefile.in (COMMON_SFILES): Add displaced-stepping.c. * aarch64-tdep.h: Include displaced-stepping.h. * displaced-stepping.h (struct displaced_step_copy_insn_closure): Move here. (displaced_step_copy_insn_closure_up): Move here. (struct buf_displaced_step_copy_insn_closure): Move here. (struct displaced_step_inferior_state): Move here. (debug_displaced): Move here. (displaced_debug_printf_1): Move here. (displaced_debug_printf): Move here. * displaced-stepping.c: New file. * gdbarch.sh: Include displaced-stepping.h in gdbarch.h. * gdbarch.h: Re-generate. * inferior.h: Include displaced-stepping.h. * infrun.h (debug_displaced): Move to displaced-stepping.h. (displaced_debug_printf_1): Likewise. (displaced_debug_printf): Likewise. (struct displaced_step_copy_insn_closure): Likewise. (displaced_step_copy_insn_closure_up): Likewise. (struct buf_displaced_step_copy_insn_closure): Likewise. (struct displaced_step_inferior_state): Likewise. * infrun.c (show_debug_displaced): Move to displaced-stepping.c. (displaced_debug_printf_1): Likewise. (displaced_step_copy_insn_closure::~displaced_step_copy_insn_closure): Likewise. (_initialize_infrun): Don't register "set/show debug displaced". Change-Id: I29935f5959b80425370630a45148fc06cd4227ca
2020-12-04gdb: pass inferior to get_linux_inferior_dataSimon Marchi2-6/+10
Pass to get_linux_inferior_data the inferior for which we want to obtain the linux-specific data, rather than assuming the current inferior. This helps slightly reduce the diff in the upcoming main patch. Update the sole caller to pass the current inferior. gdb/ChangeLog: * linux-tdep.c (get_linux_inferior_data): Add inferior parameter. (linux_vsyscall_range): Pass current inferior. Change-Id: Ie4b61190e4a2e89b5b55a140cfecd4de66d92393
2020-12-04gdb: introduce status enum for displaced step prepare/finishSimon Marchi3-30/+100
This is a preparatory patch to reduce the size of the diff of the upcoming main patch. It introduces enum types for the return values of displaced step "prepare" and "finish" operations. I find that this expresses better the intention of the code, rather than returning arbitrary integer values (-1, 0 and 1) which are difficult to remember. That makes the code easier to read. I put the new enum types in a new displaced-stepping.h file, because I introduce that file in a later patch anyway. Putting it there avoids having to move it later. There is one change in behavior for displaced_step_finish: it currently returns 0 if the thread wasn't doing a displaced step and 1 if the thread was doing a displaced step which was executed successfully. It turns out that this distinction is not needed by any caller, so I've merged these two cases into "_OK", rather than adding an extra enumerator. gdb/ChangeLog: * infrun.c (displaced_step_prepare_throw): Change return type to displaced_step_prepare_status. (displaced_step_prepare): Likewise. (displaced_step_finish): Change return type to displaced_step_finish_status. (resume_1): Adjust. (stop_all_threads): Adjust. * displaced-stepping.h: New file. Change-Id: I5c8fe07212cd398d5b486b5936d9d0807acd3788