1. 08 Dec, 2020 3 commits
    • Tom de Vries's avatar
      [gdb/testsuite] Simplify gdb.arch/amd64-gs_base.exp · b46551b2
      Tom de Vries authored
      Redo fix committed in commit 67748e0f "[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 67748e0f, reimplement
      	using is_amd64_regs_target.
      b46551b2
    • Tom de Vries's avatar
      [gdb/testsuite] Fix gdb.ada/mi_task_arg.exp for -m32 · 8439f446
      Tom de Vries authored
      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.
      8439f446
    • GDB Administrator's avatar
      Automatic date update in version.in · 28e36bf8
      GDB Administrator authored
      28e36bf8
  2. 07 Dec, 2020 15 commits
    • Pedro Alves's avatar
      gdb.base/break-on-linker-gcd-function.exp: Remove unused variable · bc545da7
      Pedro Alves authored
      Commit:
      
       commit 4d142eaa
       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.
      bc545da7
    • Nick Clifton's avatar
      Remove references to the unofficial SHF_GNU_BUILD_NOTE section flag. · 84614182
      Nick Clifton authored
      binutils	* objcopy.c (is_mergeable_note_section): Remove reference to
      	SHF_GNU_BUILD_NOTE.
      
      include	* elf/common.h (SHF_GNU_BUILD_NOTE): Delete.
      84614182
    • Siddhesh Poyarekar's avatar
      binutils: Make smart_rename safe too · 014cc7f8
      Siddhesh Poyarekar authored
      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.
      014cc7f8
    • Siddhesh Poyarekar's avatar
      objcopy: Get input file stat after BFD open · 1a1c3b4c
      Siddhesh Poyarekar authored
      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.
      1a1c3b4c
    • Siddhesh Poyarekar's avatar
      binutils: Use file descriptors from make_tempname · 365f5fb6
      Siddhesh Poyarekar authored
      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.
      365f5fb6
    • Tom Tromey's avatar
      Use expression completer for "maint print type" · a4915e8d
      Tom Tromey authored
      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".
      a4915e8d
    • Alan Modra's avatar
      [GOLD] gcc-11 stringop-overflow warning · cd8d2039
      Alan Modra authored
      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.
      cd8d2039
    • Alan Modra's avatar
      elf32-csky.c:3932:19: error: comparison is always false · fde0214a
      Alan Modra authored
      It looks like csky missed out on an edit for 706704c8.  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.
      fde0214a
    • Nick Clifton's avatar
      README-how-to-make-a-release (point releases): Add a note to update the... · a315d390
      Nick Clifton authored
      README-how-to-make-a-release (point releases): Add a note to update the milestone list on sourceware's bugzilla.
      a315d390
    • Tankut Baris Aktemur's avatar
      gdb/completer: improve tab completion to consider the '-force-condition' flag · 1f58f6c2
      Tankut Baris Aktemur authored
      The commit
      
        commit 733d554a
        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.
      1f58f6c2
    • Tankut Baris Aktemur's avatar
      gdb/linespec: relax the position of the '-force-condition' flag · 5759831a
      Tankut Baris Aktemur authored
      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".
      5759831a
    • Tankut Baris Aktemur's avatar
      gdb/main: execute breakpoint commands for '-iex' and '-ex' commands · 21e051b3
      Tankut Baris Aktemur authored
      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.
      21e051b3
    • Tom de Vries's avatar
      [gdb/ada] Handle shrink resize in replace_operator_with_call · f51f9f1d
      Tom de Vries authored
      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.
      f51f9f1d
    • Tom Tromey's avatar
      Fix struct expression regression · 00158a68
      Tom Tromey authored
      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.
      00158a68
    • GDB Administrator's avatar
      Automatic date update in version.in · 13f11b0b
      GDB Administrator authored
      13f11b0b
  3. 06 Dec, 2020 3 commits
    • Giancarlo Frix's avatar
      s390: Fix BC instruction breakpoint handling · 296cfb88
      Giancarlo Frix authored
      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.
      296cfb88
    • Joel Brobecker's avatar
      gmp-utils: protect gdb_mpz exports against out-of-range values · 63c457b9
      Joel Brobecker authored
      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.
      63c457b9
    • GDB Administrator's avatar
      Automatic date update in version.in · 6b1dce3a
      GDB Administrator authored
      6b1dce3a
  4. 05 Dec, 2020 4 commits
    • Maciej W. Rozycki's avatar
      VAX/BFD: Do not warn about GOT addend mismatches if no GOT entry is made · 0fcf331b
      Maciej W. Rozycki authored
      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.
      0fcf331b
    • Joel Brobecker's avatar
      Fix TARGET_CHAR_BIT/HOST_CHAR_BIT confusion in gmp-utils.c · 3c7ba803
      Joel Brobecker authored
      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.
      3c7ba803
    • H.J. Lu's avatar
      x86-64: Convert load to mov only for GOTPCRELX relocations · 7e45e7a9
      H.J. Lu authored
      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.
      7e45e7a9
    • GDB Administrator's avatar
      Automatic date update in version.in · 4979ae6a
      GDB Administrator authored
      4979ae6a
  5. 04 Dec, 2020 15 commits
    • Simon Marchi's avatar
      gdb: use two displaced step buffers on amd64/Linux · 372ff58f
      Simon Marchi authored
      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
      372ff58f
    • Simon Marchi's avatar
      gdb: make displaced stepping implementation capable of managing multiple buffers · 480af54c
      Simon Marchi authored
      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
      480af54c
    • Simon Marchi's avatar
      gdb: change linux gdbarch data from post to pre-init · d9655058
      Simon Marchi authored
      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
      d9655058
    • Simon Marchi's avatar
      gdb: move displaced stepping logic to gdbarch, allow starting concurrent displaced steps · 187b041e
      Simon Marchi authored
      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
      187b041e
    • Simon Marchi's avatar
      gdb: move displaced stepping types to displaced-stepping.{h,c} · c7acb87b
      Simon Marchi authored
      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
      c7acb87b
    • Simon Marchi's avatar
      gdb: pass inferior to get_linux_inferior_data · 94b24c74
      Simon Marchi authored
      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
      94b24c74
    • Simon Marchi's avatar
      gdb: introduce status enum for displaced step prepare/finish · bab37966
      Simon Marchi authored
      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
      bab37966
    • Simon Marchi's avatar
      gdb: rename displaced_step_fixup to displaced_step_finish · 7def77a1
      Simon Marchi authored
      This is a preparatory patch to reduce a little bit the diff size of the
      main patch later in this series.  It renames the displaced_step_fixup
      function in infrun.c to displaced_step_finish.
      
      The rationale is to better differentiate the low and high level
      operations.
      
      We first have the low level operation of writing an instruction to a
      displaced buffer, called "copy_insn".  The mirror low level operation to
      fix up the state after having executed the instruction is "fixup".  The
      high level operation of preparing a thread for a displaced step (which
      includes doing the "copy_insn" and some more bookkeeping) is called
      "prepare" (as in displaced_step_prepare).  The mirror high level
      operation to cleaning up after a displaced step (which includes doing
      the "fixup" and some more bookkeeping) is currently also called "fixup"
      (as in displaced_step_fixup), just like the low level operation.
      
      I think that choosing a different name for the low and high level
      cleanup operation makes it clearer, hence "finish".
      
      gdb/ChangeLog:
      
      	* infrun.c (displaced_step_fixup): Rename to...
      	(displaced_step_finish): ... this, update all callers.
      
      Change-Id: Id32f48c1e2091d09854c77fcedcc14d2519957a2
      7def77a1
    • Simon Marchi's avatar
      gdb: rename displaced_step_closure to displaced_step_copy_insn_closure · 1152d984
      Simon Marchi authored
      Since we're going to introduce other "displaced step" functions and
      another kind of displaced step closure, make it clear that this is the
      return type of the gdbarch_displaced_step_copy_insn function.
      
      gdb/ChangeLog:
      
      	* infrun.h (get_displaced_step_closure_by_addr): Rename to...
      	(get_displaced_step_copy_insn_closure_by_addr): ... this.
      	Update all users.
      	(displaced_step_closure): Rename to...
      	(displaced_step_copy_insn_closure): ... this.  Update all users.
      	(displaced_step_closure_up): Rename to...
      	(displaced_step_copy_insn_closure_up). ... this.  Update all
      	users.
      	(buf_displaced_step_closure): Rename to...
      	(buf_displaced_step_copy_insn_closure): ... this.  Update all
      	users.
      	* infrun.c (get_displaced_step_closure_by_addr): Rename to...
      	(get_displaced_step_copy_insn_closure_by_addr): ... this.
      	Update all users.
      	* aarch64-tdep.c (aarch64_displaced_step_closure): Rename to...
      	(aarch64_displaced_step_copy_insn_closure): ... this.  Update
      	all users.
      	* amd64-tdep.c (amd64_displaced_step_closure): Rename to...
      	(amd64_displaced_step_copy_insn_closure): ... this.  Update all
      	users.
      	* arm-tdep.h (arm_displaced_step_closure): Rename to...
      	(arm_displaced_step_copy_insn_closure): ... this.  Update all
      	users.
      	* i386-tdep.h (i386_displaced_step_closure): Rename to...
      	(i386_displaced_step_copy_insn_closure): ... this.  Update all
      	users.
      	* rs6000-tdep.c (ppc_displaced_step_closure): Rename to...
      	(ppc_displaced_step_copy_insn_closure): ... this.  Update all
      	users.
      	* s390-tdep.c (s390_displaced_step_closure): Rename to...
      	(s390_displaced_step_copy_insn_closure): ... this.  Update all
      	users.
      	* gdbarch.h: Re-generate.
      	* gdbarch.c: Re-generate.
      
      Change-Id: I11f56dbcd4c3532fb195a08ba93bccf1d12a03c8
      1152d984
    • Simon Marchi's avatar
      gdb: rename things related to step over chains · 28d5518b
      Simon Marchi authored
      Rename step_over_queue_head to global_thread_step_over_chain_head, to
      make it more obvious when reading code that we are touching the global
      queue.  Rename all functions that operate on it to have "global" in
      their name, to make it clear on which chain they operate on.  Also, in a
      subsequent patch, we'll need both global and non-global versions of
      these functions, so it will be easier to do the distinction if they are
      named properly.
      
      Normalize the naming to use "chain" everywhere instead of sometimes
      "queue", sometimes "chain".
      
      I also reworded a few comments in gdbthread.h.  They implied that the
      step over chain is per-inferior, when in reality there is only one
      global chain, not one per inferior, as far as I understand.
      
      gdb/ChangeLog:
      
      	* gdbthread.h (thread_step_over_chain_enqueue): Rename to...
      	(global_thread_step_over_chain_enqueue): ... this.  Update all
      	users.
      	(thread_step_over_chain_remove): Rename to...
      	(global_thread_step_over_chain_remove): ... this.  Update all
      	users.
      	(thread_step_over_chain_next): Rename to...
      	(global_thread_step_over_chain_next): ... this.  Update all
      	users.
      	* infrun.h (step_over_queue_head): Rename to...
      	(global_thread_step_over_chain_head): ... this.  Update all
      	users.
      	* infrun.c (step_over_queue_head): Rename to...
      	(global_thread_step_over_chain_head): ... this.  Update all
      	users.
      	* thread.c (step_over_chain_remove): Rename to...
      	(thread_step_over_chain_remove): ... this.  Update all users.
      	(thread_step_over_chain_next): Rename to...
      	(global_thread_step_over_chain_next): ... this.  Update all
      	users.
      	(thread_step_over_chain_enqueue): Rename to...
      	(global_thread_step_over_chain_enqueue): ... this.  Update all
      	users.
      	(thread_step_over_chain_remove): Rename to...
      	(global_thread_step_over_chain_remove): ... this.  Update all
      	users.
      
      Change-Id: Iabbf57d83c01321ca199d83fadb57f5b04e4d6d9
      28d5518b
    • Simon Marchi's avatar
      gdb: get rid of get_displaced_stepping_state · f5f01699
      Simon Marchi authored
      Remove function get_displaced_stepping_state.  When it was introduced,
      inferiors' displaced stepping state was kept in a linked list in
      infrun.c, so it was handy.  Nowadays, the state is kept inside struct
      inferior directly, so we can just access it directly instead.
      
      gdb/ChangeLog:
      
      	* infrun.c (get_displaced_stepping_state): Remove, change
      	callers to access the field directly.
      
      Change-Id: I9a733e32e29c7ebf856ab0befe1076bbb8c7af69
      f5f01699
    • Simon Marchi's avatar
      gdb: restore displaced step buffer bytes when another thread forks · c0aba012
      Simon Marchi authored
      In handle_inferior_event, where we handle forks, we make sure to restore
      the bytes of the displaced stepping buffer in the child's address
      space.  However, we only do it when the forking thread was the one
      doing a displaced step.  It could happen that a thread forks while
      another one is doing a displaced step.  In this case, we also need to
      restore the bytes in the child.
      
      Move the byte-restoring code outside of the condition that checks
      whether the event thread was displaced stepping.
      
      gdb/ChangeLog:
      
      	* infrun.c (handle_inferior_event): Restore displaced step
      	buffer bytes in child process when handling fork, even if fork
      	happened in another thread than the displaced-stepping one.
      
      Change-Id: Ibb0daaeb123aba03f4fb4b4d820754eb2436bc69
      c0aba012
    • Simon Marchi's avatar
      gdb: clear inferior displaced stepping state and in-line step-over info on exec · 3b7a962d
      Simon Marchi authored
      When a process does an exec, all its program space is replaced with the
      newly loaded executable.  All non-main threads disappear and the main
      thread starts executing at the entry point of the new executable.
      
      Things can go wrong if a displaced step operation is in progress while
      we process the exec event.
      
      If the main thread is the one executing the displaced step: when that
      thread (now executing in the new executable) stops somewhere (say, at a
      breakpoint), displaced_step_fixup will run and clear up the state.  We
      will execute the "fixup" phase for the instruction we single-stepped in
      the old program space.  We are now in a completely different context,
      so doing the fixup may corrupt the state.
      
      If it is a non-main thread that is doing the displaced step: while
      handling the exec event, GDB deletes the thread_info representing that
      thread (since the thread doesn't exist in the inferior after the exec).
      But inferior::displaced_step_state::step_thread will still point to it.
      When handling events later, this condition, in displaced_step_fixup,
      will likely never be true:
      
          /* Was this event for the thread we displaced?  */
          if (displaced->step_thread != event_thread)
            return 0;
      
      ... since displaced->step_thread points to a deleted thread (unless that
      storage gets re-used for a new thread_info, but that wouldn't be good
      either).  This effectively makes the displaced stepping buffer occupied
      for ever.  When a thread in the new program space will want to do a
      displaced step, it will wait for ever.
      
      I think we simply need to reset the displaced stepping state of the
      inferior on exec.  Everything execution-related that existed before the
      exec is now gone.
      
      Similarly, if a thread does an in-line step over an exec syscall
      instruction, nothing clears the in-line step over info when the event is
      handled.  So it the in-line step over info stays there indefinitely, and
      things hang because we can never start another step over.  To fix this,
      I added a call to clear_step_over_info in infrun_inferior_execd.
      
      Add a test with a program with two threads that does an exec.  The test
      includes the following axes:
      
      - whether it's the leader thread or the other thread that does the exec.
      
      - whether the exec'r and exec'd program have different text segment
        addresses.  This is to hopefully catch cases where the displaced
        stepping info doesn't get reset, and GDB later tries to restore bytes
        of the old address space in the new address space.  If the mapped
        addresses are different, we should get some memory error.   This
        happens without the patch applied:
      
        $ ./gdb -q -nx --data-directory=data-directory testsuite/outputs/gdb.threads/step-over-exec/step-over-exec-execr-thread-leader-diff-text-segs-true -ex "b main" -ex r -ex "b my_execve_syscall if 0"  -ex "set displaced-stepping on"
        ...
        Breakpoint 1, main (argc=1, argv=0x7fffffffde38) at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.threads/step-over-exec.c:69
        69        argv0 = argv[0];
        Breakpoint 2 at 0x60133a: file /home/simark/src/binutils-gdb/gdb/testsuite/lib/my-syscalls.S, line 34.
        (gdb) c
        Continuing.
        [New Thread 0x7ffff7c62640 (LWP 1455423)]
        Leader going in exec.
        Exec-ing /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-over-exec/step-over-exec-execr-thread-leader-diff-text-segs-true-execd
        [Thread 0x7ffff7c62640 (LWP 1455423) exited]
        process 1455418 is executing new program: /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-over-exec/step-over-exec-execr-thread-leader-diff-text-segs-true-execd
        Error in re-setting breakpoint 2: Function "my_execve_syscall" not defined.
        No unwaited-for children left.
        (gdb) n
        Single stepping until exit from function _start,
        which has no line number information.
        Cannot access memory at address 0x6010d2
        (gdb)
      
      - Whether displaced stepping is allowed or not, so that we end up
        testing both displaced stepping and in-line stepping on arches that do
        support displaced stepping (otherwise, it just tests in-line stepping
        twice I suppose)
      
      To be able to precisely put a breakpoint on the syscall instruction, I
      added a small assembly file (lib/my-syscalls.S) that contains minimal
      Linux syscall wrappers.  I prefer that to the strategy used in
      gdb.base/step-over-syscall.exp, which is to stepi into the glibc wrapper
      until we find something that looks like a syscall instruction, I find
      that more predictable.
      
      gdb/ChangeLog:
      
      	* infrun.c (infrun_inferior_execd): New function.
      	(_initialize_infrun): Attach inferior_execd observer.
      
      gdb/testsuite/ChangeLog:
      
      	* gdb.threads/step-over-exec.exp: New.
      	* gdb.threads/step-over-exec.c: New.
      	* gdb.threads/step-over-exec-execd.c: New.
      	* lib/my-syscalls.S: New.
      	* lib/my-syscalls.h: New.
      
      Change-Id: I1bbc8538e683f53af5b980091849086f4fec5ff9
      3b7a962d
    • Simon Marchi's avatar
      gdb: add inferior_execd observable · 42a4fec5
      Simon Marchi authored
      I want to add another action (clearing displaced stepping state) that
      happens when an inferior execs.  I think it would be cleaner to have an
      observer for this event, rather than have infrun know about each other
      sub-component.
      
      Replace the calls to solib_create_inferior_hook and
      jit_inferior_created_hook in follow_exec by observers.
      
      gdb/ChangeLog:
      
      	* observable.h (inferior_execd): Declare new observable.
      	* observable.c (inferior_execd): Declare new observable.
      	* infrun.c (follow_exec): Notify inferior_execd observer.
      	* jit.c (jit_inferior_created_hook): Make static.
      	(_initialize_jit): Register inferior_execd observer.
      	* jit.h (jit_inferior_created_hook): Remove declaration.
      	* solib.c (_initialize_solib): Register inferior_execd observer.
      
      Change-Id: I000cce00094e23baa67df693d912646b6ae38e44
      42a4fec5
    • Tom de Vries's avatar
      [gdb] Fix heap-buffer-overflow in completion_tracker::build_completion_result · aafdfb4e
      Tom de Vries authored
      When building gdb with address sanitizer and running test-case
      gdb.base/completion.exp, we run into:
      ...
      ==5743==ERROR: AddressSanitizer: heap-buffer-overflow on address \
        0x60200025c02f at pc 0x000000cd9d64 bp 0x7fff3297da30 sp 0x7fff3297da28
      READ of size 1 at 0x60200025c02f thread T0
          #0 0xcd9d63 in completion_tracker::build_completion_result(char const*, \
                           int, int) gdb/completer.c:2258
        ...
      0x60200025c02f is located 1 bytes to the left of 1-byte region \
        [0x60200025c030,0x60200025c031)
      ...
      
      This can be reproduced using just:
      ...
      $ gdb
      (gdb) p/d[TAB]
      ...
      
      The problem is in this code in completion_tracker::build_completion_result:
      ...
            bool completion_suppress_append
              = (suppress_append_ws ()
                 || match_list[0][strlen (match_list[0]) - 1] == ' ');
      ...
      If strlen (match_list[0]) == 0, then we access match_list[0][-1].
      
      Fix this by testing if the memory access is in bounds before doing the memory
      access.
      
      Tested on x86_64-linux.
      
      gdb/ChangeLog:
      
      2020-12-04  Tom de Vries  <tdevries@suse.de>
      
      	PR gdb/27003
      	* completer.c (completion_tracker::build_completion_result): Don't
      	access match_list[0][-1].
      aafdfb4e