1. 31 Jan, 2018 2 commits
  2. 30 Jan, 2018 1 commit
  3. 29 Jan, 2018 1 commit
  4. 28 Jan, 2018 1 commit
  5. 27 Jan, 2018 3 commits
    • Eli Zaretskii's avatar
      Avoid compilation errors in MinGW native builds of GDB · 0b2b7215
      Eli Zaretskii authored
      The error is triggered by including python-internal.h, and the
      error message is:
      
           In file included from d:\usr\lib\gcc\mingw32\6.3.0\include\c++\math.h:36:0,
      	      from build-gnulib/import/math.h:27,
      	      from d:/usr/Python26/include/pyport.h:235,
      	      from d:/usr/Python26/include/Python.h:58,
      	      from python/python-internal.h:94,
      	      from python/py-arch.c:24:
           d:\usr\lib\gcc\mingw32\6.3.0\include\c++\cmath:1157:11: error: '::hypot' has not been declared
              using ::hypot;
      	        ^~~~~
      
      This happens because Python headers define 'hypot' to expand to
      '_hypot' in the Windows builds.
      
      gdb/ChangeLog:
      2018-01-27  Eli Zaretskii  <eliz@gnu.org>
      
      	* python/python-internal.h (_hypot) [__MINGW32__]: Define back to
      	'hypoth'.  This avoids a compilation error.
      
      (cherry picked from commit b2a426e2)
      0b2b7215
    • Eli Zaretskii's avatar
      Avoid compilation warning in libiberty/simple-object-xcoff.c · 3d721be4
      Eli Zaretskii authored
      gdb/ChangeLog:
      2018-01-27  Eli Zaretskii  <eliz@gnu.org>
      
      	* simple-object-xcoff.c (simple_object_xcoff_find_sections): Avoid
      	compilation warning in 32-bit builds not supported by
      	AC_SYS_LARGEFILE.
      
      (cherry picked from commit de54ee81)
      3d721be4
    • GDB Administrator's avatar
      Automatic date update in version.in · c31aef47
      GDB Administrator authored
      c31aef47
  6. 26 Jan, 2018 1 commit
  7. 25 Jan, 2018 1 commit
  8. 24 Jan, 2018 2 commits
    • Pedro Alves's avatar
      Fix GCC PR83906 - [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4 · 76112dde
      Pedro Alves authored
      GCC PR83906 [1] is about a GCC/libstdc++ GDB/Python type printer
      testcase failing randomly, as shown by running (in libstdc++'s
      testsuite):
      
       make check RUNTESTFLAGS=prettyprinters.exp=80276.cc
      
      in a loop.  Sometimes you get this:
      
       FAIL: libstdc++-prettyprinters/80276.cc whatis p4
      
      I.e., this:
       type = std::unique_ptr<std::vector<std::unique_ptr<std::list<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >>[]>>[99]>
      
      instead of this:
       type = std::unique_ptr<std::vector<std::unique_ptr<std::list<std::string>[]>>[99]>
      
      Jonathan Wakely tracked it on the printer side to this bit in
      libstdc++'s type printer:
      
                  if self.type_obj == type_obj:
                      return strip_inline_namespaces(self.name)
      
      This assumes the two types resolve to the same gdb.Type but some times
      the comparison unexpectedly fails.
      
      Running the testcase manually under Valgrind finds the problem in GDB:
      
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       ==6118== Conditional jump or move depends on uninitialised value(s)
       ==6118==    at 0x4C35CB0: bcmp (vg_replace_strmem.c:1100)
       ==6118==    by 0x6F773A: check_types_equal(type*, type*, VEC_type_equality_entry_d**) (gdbtypes.c:3515)
       ==6118==    by 0x6F7B00: check_types_worklist(VEC_type_equality_entry_d**, bcache*) (gdbtypes.c:3618)
       ==6118==    by 0x6F7C03: types_deeply_equal(type*, type*) (gdbtypes.c:3655)
       ==6118==    by 0x4D5B06: typy_richcompare(_object*, _object*, int) (py-type.c:1007)
       ==6118==    by 0x63D7E6C: PyObject_RichCompare (object.c:961)
       ==6118==    by 0x646EAEC: PyEval_EvalFrameEx (ceval.c:4960)
       ==6118==    by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519)
       ==6118==    by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519)
       ==6118==    by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519)
       ==6118==    by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519)
       ==6118==    by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519)
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      That "bcmp" call is really a memcmp call in check_types_equal.  The
      problem is that gdb is memcmp'ing two objects that are equal in value:
      
       (top-gdb) p *TYPE_RANGE_DATA (type1)
       $1 = {low = {kind = PROP_CONST, data = {const_val = 0, baton = 0x0}}, high = {kind = PROP_CONST, data = {const_val = 15, baton = 0xf}}, flag_upper_bound_is_count = 0,
         flag_bound_evaluated = 0}
       (top-gdb) p *TYPE_RANGE_DATA (type2)
       $2 = {low = {kind = PROP_CONST, data = {const_val = 0, baton = 0x0}}, high = {kind = PROP_CONST, data = {const_val = 15, baton = 0xf}}, flag_upper_bound_is_count = 0,
         flag_bound_evaluated = 0}
      
      but differ in padding.  Notice the 4-byte hole:
      
        (top-gdb) ptype /o range_bounds
        /* offset    |  size */  type = struct range_bounds {
        /*    0      |    16 */    struct dynamic_prop {
        /*    0      |     4 */        dynamic_prop_kind kind;
        /* XXX  4-byte hole  */
        /*    8      |     8 */        union dynamic_prop_data {
        /*                 8 */            LONGEST const_val;
        /*                 8 */            void *baton;
      
      				     /* total size (bytes):    8 */
      				 } data;
      
      which is filled with garbage:
      
        (top-gdb) x /40bx TYPE_RANGE_DATA (type1)
        0x2fa7ea0:      0x01    0x00    0x00    0x00    0x43    0x01    0x00    0x00
      						  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        0x2fa7ea8:      0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
        0x2fa7eb0:      0x01    0x00    0x00    0x00    0xfe    0x7f    0x00    0x00
        0x2fa7eb8:      0x0f    0x00    0x00    0x00    0x00    0x00    0x00    0x00
        0x2fa7ec0:      0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
        (top-gdb) x /40bx TYPE_RANGE_DATA (type2)
        0x20379b0:      0x01    0x00    0x00    0x00    0xfe    0x7f    0x00    0x00
      						  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        0x20379b8:      0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
        0x20379c0:      0x01    0x00    0x00    0x00    0xfe    0x7f    0x00    0x00
        0x20379c8:      0x0f    0x00    0x00    0x00    0x00    0x00    0x00    0x00
        0x20379d0:      0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
      
        (top-gdb) p memcmp (TYPE_RANGE_DATA (type1), TYPE_RANGE_DATA (type2), sizeof (*TYPE_RANGE_DATA (type1)))
        $3 = -187
      
      In some cases objects of type range_bounds are memset when allocated,
      but then their dynamic_prop low/high fields are copied over from some
      template dynamic_prop object that wasn't memset.  E.g.,
      create_static_range_type's low/high locals are left with garbage in
      the padding, and then that padding is copied over to the range_bounds
      object's low/high fields.
      
      At first, I considered making sure to always memset range_bounds
      objects, thinking that maybe type objects are being put in some bcache
      instance somewhere.  But then I hacked bcache/bcache_full to poison
      non-pod types, and made dynamic_prop a non-pod, and GDB still
      compiled.
      
      So given that, it seems safest to not assume padding will always be
      memset, and instead treat them as regular value types, implementing
      (in)equality operators and using those instead of memcmp.
      
      This fixes the random FAILs in GCC's testcase.
      
      [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906
      
      gdb/ChangeLog:
      2018-01-24  Pedro Alves  <palves@redhat.com>
      
      	GCC PR libstdc++/83906
      	* gdbtypes.c (operator==(const dynamic_prop &,
      	const dynamic_prop &)): New.
      	(operator==(const range_bounds &, const range_bounds &)): New.
      	(check_types_equal): Use them instead of memcmp.
      	* gdbtypes.h (operator==(const dynamic_prop &,
      	const dynamic_prop &)): Declare.
      	(operator!=(const dynamic_prop &, const dynamic_prop &)): Declare.
      	(operator==(const range_bounds &, const range_bounds &)): Declare.
      	(operator!=(const range_bounds &, const range_bounds &)): Declare.
      76112dde
    • GDB Administrator's avatar
      Automatic date update in version.in · 374a66a0
      GDB Administrator authored
      374a66a0
  9. 23 Jan, 2018 1 commit
  10. 22 Jan, 2018 3 commits
    • Maciej W. Rozycki's avatar
      MAINTAINERS: Update my company e-mail address · fd37310f
      Maciej W. Rozycki authored
      Following my recent transition from Imagination Technologies to the
      reincarnated MIPS company update MAINTAINERS entries accordingly.
      
      	binutils/
      	* MAINTAINERS: Update my company e-mail address.
      
      	gdb/
      	* MAINTAINERS: Update my company e-mail address.
      
      	sim/
      	* MAINTAINERS: Update my company e-mail address.
      
      (cherry picked from commit d65ce302)
      fd37310f
    • Pedro Alves's avatar
      Fix segfault with 'set print object on' + 'whatis <struct>' & co · ddd0c99d
      Pedro Alves authored
      Compiling GDB with a recent GCC exposes a problem:
      
        ../../gdb/typeprint.c: In function 'void whatis_exp(const char*, int)':
        ../../gdb/typeprint.c:515:12: warning: 'val' may be used uninitialized in this function [-Wmaybe-uninitialized]
          real_type = value_rtti_type (val, &full, &top, &using_enc);
          ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      The warning is correct.  There are indeed code paths that use
      uninitialized 'val', leading to crashes.  Inside the
      value_rtti_indirect_type/value_rtti_type calls here in whatis_exp:
      
        if (opts.objectprint)
          {
            if (((TYPE_CODE (type) == TYPE_CODE_PTR) || TYPE_IS_REFERENCE (type))
      	  && (TYPE_CODE (TYPE_TARGET_TYPE (type)) == TYPE_CODE_STRUCT))
              real_type = value_rtti_indirect_type (val, &full, &top, &using_enc);
            else if (TYPE_CODE (type) == TYPE_CODE_STRUCT)
      	real_type = value_rtti_type (val, &full, &top, &using_enc);
          }
      
      We reach those calls above with "set print object on", and then with
      any of:
      
        (gdb) whatis struct some_structure_type
        (gdb) whatis struct some_structure_type *
        (gdb) whatis struct some_structure_type &
      
      because "whatis" with a type argument enters this branch:
      
            /* The behavior of "whatis" depends on whether the user
      	 expression names a type directly, or a language expression
      	 (including variable names).  If the former, then "whatis"
      	 strips one level of typedefs, only.  If an expression,
      	 "whatis" prints the type of the expression without stripping
      	 any typedef level.  "ptype" always strips all levels of
      	 typedefs.  */
            if (show == -1 && expr->elts[0].opcode == OP_TYPE)
      	{
      
      which does not initialize VAL.  Trying the above triggers crashes like
      this:
      
        (gdb) set print object on
        (gdb) whatis some_structure_type
      
        Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
        0x00000000005dda90 in check_typedef (type=0x6120736573756170) at src/gdb/gdbtypes.c:2388
        2388      int instance_flags = TYPE_INSTANCE_FLAGS (type);
        ...
      
      This is a regression caused by a recent-ish refactoring of the code on
      'whatis_exp', introduced by:
      
        commit c973d0aa
        Date:   Mon Aug 21 11:34:32 2017 +0100
      
            Fix type casts losing typedefs and reimplement "whatis" typedef stripping
      
      Fix this by setting VAL to NULL in the "whatis TYPE" case, and
      skipping fetching the dynamic type if there's no value to fetch it
      from.
      
      New tests included.
      
      gdb/ChangeLog:
      2018-01-22  Pedro Alves  <palves@redhat.com>
      	    Sergio Durigan Junior  <sergiodj@redhat.com>
      
      	* typeprint.c (whatis_exp): Initialize "val" in the "whatis type"
      	case.
      
      gdb/testsuite/ChangeLog:
      2018-01-22  Pedro Alves  <palves@redhat.com>
      	    Sergio Durigan Junior  <sergiodj@redhat.com>
      
      	* gdb.base/whatis.exp: Add tests for 'set print object on' +
      	'whatis <struct>' 'whatis <struct> *' and 'whatis <struct> &'.
      ddd0c99d
    • GDB Administrator's avatar
      Automatic date update in version.in · 5dc31b7c
      GDB Administrator authored
      5dc31b7c
  11. 21 Jan, 2018 1 commit
  12. 20 Jan, 2018 1 commit
  13. 19 Jan, 2018 1 commit
  14. 18 Jan, 2018 1 commit
  15. 17 Jan, 2018 5 commits
    • Sergio Durigan Junior's avatar
      Fix warning on gdb/compile/compile.c (C++-ify "triplet_rx") · 2a54d215
      Sergio Durigan Junior authored
      This fixes a GCC warning that happens when compiling
      gdb/compile/compile.c on some GCC versions (e.g., "gcc (GCC) 7.2.1
      20180104 (Red Hat 7.2.1-6)"):
      
      ../../gdb/compile/compile.c: In function 'void eval_compile_command(command_line*, const char*, compile_i_scope_types, void*)':
      ../../gdb/compile/compile.c:548:19: warning: 'triplet_rx' may be used uninitialized in this function [-Wmaybe-uninitialized]
           error_message = compiler->fe->ops->set_arguments_v0 (compiler->fe, triplet_rx,
           ~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
               argc, argv);
               ~~~~~~~~~~~
      ../../gdb/compile/compile.c:466:9: note: 'triplet_rx' was declared here
         char *triplet_rx;
               ^~~~~~~~~~
      
      It's a simple patch that converts "triplet_rx" from "char *" to
      "std::string", thus guaranteeing that it will be always initialized.
      
      I've regtested this patch and did not find any regressions.  OK to
      apply on both master and 8.1 (after creating a bug for it)?
      
      gdb/ChangeLog:
      2018-01-17  Sergio Durigan Junior  <sergiodj@redhat.com>
      
      	* compile/compile.c (compile_to_object): Convert "triplet_rx"
      	to "std::string".
      2a54d215
    • Eldar Abusalimov's avatar
      configure: Fix test for fs_base/gs_base in <sys/user.h> · 6949085e
      Eldar Abusalimov authored
      Make <sys/types.h> be included prior to including <sys/user.h>.
      
      glibc versions older than 2.14 use __uintNN_t types within certain
      structures defined in <sys/user.h> probably assuming these types are
      defined prior to including the header. This results in the following
      `configure` feature test compilation error that makes it think that
      `struct user_regs_struct` doesn't have `fs_base`/`gs_base` fields,
      althouh it does.
      
          configure:13617: checking for struct user_regs_struct.fs_base
          configure:13617: gcc -c -g -O2 -I/linux/include conftest.c >&5
          In file included from conftest.c:158:0:
          /usr/include/sys/user.h:32:3: error: unknown type name '__uint16_t'
             __uint16_t  cwd;
             ^
          /usr/include/sys/user.h:33:3: error: unknown type name '__uint16_t'
             __uint16_t  swd;
             ^
          /usr/include/sys/user.h:34:3: error: unknown type name '__uint16_t'
             __uint16_t  ftw;
             ^
          /usr/include/sys/user.h:35:3: error: unknown type name '__uint16_t'
             __uint16_t  fop;
             ^
          /usr/include/sys/user.h:36:3: error: unknown type name '__uint64_t'
             __uint64_t  rip;
             ^
          /usr/include/sys/user.h:37:3: error: unknown type name '__uint64_t'
             __uint64_t  rdp;
             ^
          /usr/include/sys/user.h:38:3: error: unknown type name '__uint32_t'
             __uint32_t  mxcsr;
             ^
          /usr/include/sys/user.h:39:3: error: unknown type name '__uint32_t'
             __uint32_t  mxcr_mask;
             ^
          /usr/include/sys/user.h:40:3: error: unknown type name '__uint32_t'
             __uint32_t  st_space[32];   /* 8*16 bytes for each FP-reg = 128 bytes */
             ^
          /usr/include/sys/user.h:41:3: error: unknown type name '__uint32_t'
             __uint32_t  xmm_space[64];  /* 16*16 bytes for each XMM-reg = 256 bytes */
             ^
          /usr/include/sys/user.h:42:3: error: unknown type name '__uint32_t'
             __uint32_t  padding[24];
             ^
          configure:13617: $? = 1
          configure: failed program was:
          | /* confdefs.h */
          ...
          | /* end confdefs.h.  */
          | #include <sys/user.h>
          |
          | int
          | main ()
          | {
          | static struct user_regs_struct ac_aggr;
          | if (ac_aggr.fs_base)
          | return 0;
          |   ;
          |   return 0;
          | }
      
      Recent glibc versions don't use typedef'ed int types in <sys/user.h>,
      thus allowing it to be included as is
      (glibc commit d79a9c949c84e7f0ba33e87447c47af833e9f11a).
      However there're still some distros alive that use older glibc,
      for instance, RHEL/CentOS 6 package glibc 2.12.
      
      Also affects PR gdb/21559:
      
          ../../gdb/regcache.c:1087: internal-error: void regcache_raw_supply(regcache, int, const void): Assertion `regnum >= 0 && regnum < regcache->descr->nr_raw_registers' failed.
      
      As noted by Andrew Paprocki, who submitted the PR
      (https://sourceware.org/bugzilla/show_bug.cgi?id=21559#c3):
      
          > It should be noted that modifying `configure` to force on
          > `HAVE_STRUCT_USER_REGS_STRUCT_FS_BASE` and
          > `HAVE_STRUCT_USER_REGS_STRUCT_GS_BASE` fixes this issue. For some
          > reason the `configure` tests for `fs_base` and `gs_base` fail
          > even though `sys/user.h` on RHEL5 has the fields defined in
          > `user_regs_struct`.
      
      Note that this patch does NOT fix the root cause of PR gdb/21559,
      although now that `configure` properly detects the presence of the
      fields and sets HAVE_XXX accordingly, the execution takes another
      path, which doesn't lead to the assertion failure in question.
      
      gdb/ChangeLog:
      2018-01-17  Eldar Abusalimov  <eldar.abusalimov@jetbrains.com>
      
      	PR gdb/21559
      	* configure.ac: Include <sys/types.h> prior to <sys/user.h> when
      	checking for fs_base/gs_base fields in struct user_regs_struct.
      	* configure: Regenerate.
      
      gdb/gdbserver/ChangeLog:
      2018-01-17  Eldar Abusalimov  <eldar.abusalimov@jetbrains.com>
      
      	PR gdb/21559
      	* configure.ac: Include <sys/types.h> prior to <sys/user.h> when
      	checking for fs_base/gs_base fields in struct user_regs_struct.
      	* configure: Regenerate.
      6949085e
    • Yao Qi's avatar
      Don't pass -m64 to libcc1 on aarch64-linux. · 94485cac
      Yao Qi authored
      Nowadays, if we use "compile" on aarch64-linux, we'll get the following
      error,
      
      (gdb) compile code -- ;
      aarch64-none-linux-gnu-gcc: error: unrecognized command line option '-m64'
      
      because the default gcc_target_options returns "-m64" and
      "-mcmodel=large", neither is useful to aarch64-linux.
      
      gdb:
      
      2018-01-17  Yao Qi  <yao.qi@linaro.org>
      
      	* aarch64-linux-tdep.c (aarch64_linux_gcc_target_options): New
      	function.
      	(aarch64_linux_init_abi): Install it to gdbarch hook
      	gcc_target_options.
      94485cac
    • Yao Qi's avatar
      Relax gdb.compile/compile.exp to match the address printed for frame · 862f0945
      Yao Qi authored
      One test in gdb.compile/compile.exp passes on one fedora builder,
      
       bt
       #0  0x00007ffff7ff43f6 in _gdb_expr (__regs=0x7ffff7ff2000) at gdb
       command line:1^M
       #1  <function called from gdb>^M
       #2  main () at /home/gdb-buildbot/fedora-x86-64-1/fedora-x86-64/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.compile/compile.c:106^M
       (gdb) PASS: gdb.compile/compile.exp: bt
      
      but fails on my machine with gcc trunk,
      
       bt^M
       #0  _gdb_expr (__regs=0x7ffff7ff3000) at gdb command line:1^M
       #1  <function called from gdb>^M
       #2  main () at gdb/testsuite/gdb.compile/compile.c:106^M
       (gdb) FAIL: gdb.compile/compile.exp: bt
      
      The test should be tweaked to match both cases (pc in the start of line
      vs pc in the middle of line).  Note that I am not clear that why libcc1
      emits debug info this way so that the address is in the middle of line.
      
      gdb/testsuite:
      
      2018-01-17  Yao Qi  <yao.qi@linaro.org>
      
      	* gdb.compile/compile.exp: Match the address printed for
      	frame in the output of command "bt".
      862f0945
    • GDB Administrator's avatar
      Automatic date update in version.in · 1049cf3b
      GDB Administrator authored
      1049cf3b
  16. 16 Jan, 2018 1 commit
  17. 15 Jan, 2018 2 commits
    • Tom Tromey's avatar
      Fix scm-ports.exp regression · 5429afd6
      Tom Tromey authored
      In https://sourceware.org/ml/gdb-patches/2017-12/msg00215.html, Jan
      pointed out that the scalar printing patches caused a regression in
      scm-ports.exp on x86.
      
      What happens is that on x86, this:
      
      	set sp_reg [get_integer_valueof "\$sp" 0]
      
      ... ends up setting sp_reg to a negative value, because
      get_integer_valueof uses "print/d":
      
          print /d $sp
          $1 = -11496
      
      Then later the test suite does:
      
          gdb_test "guile (print (seek rw-mem-port (value->integer sp-reg) SEEK_SET))" \
      	"= $sp_reg" \
      	"seek to \$sp"
      
      ... expecting this value to be identical to the saved $sp_reg value.
      However it gets:
      
          guile (print (seek rw-mem-port (value->integer sp-reg) SEEK_SET))
          = 4294955800
      
      "print" is just a wrapper for guile's format:
      
          gdb_test_no_output "guile (define (print x) (format #t \"= ~A\" x) (newline))"
      
      The seek function returns a scm_t_off, the printing of which is
      handled by guile, not by gdb.
      
      Tested on x86-64 Fedora 26 using an ordinary build and also a -m32
      build.
      
      2018-01-15  Tom Tromey  <tom@tromey.com>
      
      	* gdb.guile/scm-ports.exp (test_mem_port_rw): Use get_valueof to
      	compute sp_reg.
      5429afd6
    • GDB Administrator's avatar
      Automatic date update in version.in · 503a19e5
      GDB Administrator authored
      503a19e5
  18. 14 Jan, 2018 1 commit
  19. 13 Jan, 2018 1 commit
  20. 12 Jan, 2018 7 commits
    • Pedro Alves's avatar
      Add testcase for GDB hang fixed by previous commit · 1d170255
      Pedro Alves authored
      This adds a testcase for the previous commit.  The regression was
      related to in-line step overs.  The reason we didn't see it on native
      x86-64/s390 GNU/Linux testing is that native debugging uses displaced
      stepping by default (because native debugging defaults to "maint set
      target-non-stop on"), unlike remote debugging.
      
      So in order to trigger the bug with native debugging as well, the
      testcase disables displaced stepping explicitly.
      
      Also, instead of using watchpoints to trigger the regression, the
      testcase uses a breakpoint at address 0, which should be more
      portable.
      
      gdb/testsuite/ChangeLog:
      2018-01-12  Pedro Alves  <palves@redhat.com>
      
      	* gdb.base/continue-after-aborted-step-over.c: New.
      	* gdb.base/continue-after-aborted-step-over.exp: New.
      1d170255
    • Andreas Arnez's avatar
      Fix GDB hang with remote after error from resume · a09f837a
      Andreas Arnez authored
      Since this commit --
      
        Fix PR18360 - internal error when using "interrupt -a"
        (https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=c65d6b55)
      
      -- the testsuite shows long delays on s390 with native-gdbserver when
      executing certain tests, such as watchpoints.exp.  These hangs have been
      discussed before in the context of buildbot problems, see here:
      
        https://sourceware.org/ml/gdb-patches/2017-12/msg00413.html
      
      The problem can easily be triggered by stopping on a breakpoint, then
      setting impossible watchpoints, and finally doing "continue".  Then, after
      having set the step-over state (in keep_going_pass_signal in infrun.c),
      GDB tries to insert breakpoints and watchpoints into the inferior.  This
      fails, and the "continue" command is aborted.  But the step-over state is
      not cleared in this case, which causes future step-over attempts to be
      skipped since GDB thinks that "we already have an in-line step-over
      operation ongoing" (see start_step_over in infrun.c).  Thus the next
      "continue" just goes on to wait for events from the remote, which will
      never occur.
      
      The problem can also be reproduced on amd64 with native-gdbserver, using
      the following change to watchpoints.exp:
      
       -- >8 --
       --- a/gdb/testsuite/gdb.base/watchpoints.exp
       +++ b/gdb/testsuite/gdb.base/watchpoints.exp
       @@ -61,2 +61,3 @@ with_test_prefix "before inferior start" {
            gdb_test "watch ival3" ".*" ""
       +    gdb_test "watch *(char \[256\] *) main"
      
       -- >8 --
      
      To fix the hang, this patch clears the step-over info when
      insert_breakpoints has failed.  Of course, with native-gdbserver the
      watchpoints.exp test case still causes many FAILs on s390, because
      gdbserver does not support watchpoints for that target.  This is a
      separate issue.
      
      gdb/ChangeLog:
      2018-01-12  Andreas Arnez  <arnez@linux.vnet.ibm.com>
      
      	* infrun.c (keep_going_pass_signal): Clear step-over info when
      	insert_breakpoints fails.
      a09f837a
    • Joel Brobecker's avatar
      Bump GDB version number to 8.0.91.DATE-git. · 4d8dd3e1
      Joel Brobecker authored
      gdb/ChangeLog:
      
      	* version.in: Set GDB version number to 8.0.91.DATE-git.
      	* PROBLEMS: Likewise.
      4d8dd3e1
    • Joel Brobecker's avatar
      Document the GDB 8.0.91 release in gdb/ChangeLog · 4be8da4b
      Joel Brobecker authored
      gdb/ChangeLog:
      
      	GDB 8.0.91 released.
      4be8da4b
    • Joel Brobecker's avatar
      Set GDB version number to 8.0.91. · 556dbf30
      Joel Brobecker authored
      gdb/ChangeLog:
      
      	* version.in: Set GDB version number to 8.0.91.
      	* PROBLEMS: Likewise.
      556dbf30
    • Joel Brobecker's avatar
      gdb/NEWS: Rename "Changes since 8.0" into "Changes in 8.1". · 93935fd4
      Joel Brobecker authored
      gdb/ChangeLog:
      
              * NEWS: Rename "Changes since 8.0" into "Changes in 8.1".
      93935fd4
    • GDB Administrator's avatar
      Automatic date update in version.in · 0d4a30a8
      GDB Administrator authored
      0d4a30a8
  21. 11 Jan, 2018 3 commits
    • Pedro Alves's avatar
      gdb.base/breakpoint-in-ro-region.exp regression on sss targets (PR gdb/22583) · f740fa50
      Pedro Alves authored
      As Maciej reported at
      <https://sourceware.org/ml/gdb-patches/2017-12/msg00212.html>, this
      commit:
      
       commit d930703d
       Date: Thu Nov 16 18:44:43 2017 +0000
       Subject: Don't ever Quit out of resume
      
      caused regressions on software single-set targets, specifically:
      
       FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw off: single-step breakpoint is not left behind
       FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw on: single-step breakpoint is not left behind
       FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted on: auto-hw off: step in ro region (cannot insert hw break)
       FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted on: auto-hw off: single-step breakpoint is not left behind
       FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted on: auto-hw on: single-step breakpoint is not left behind
      
      and indeed detailed logs indicate a breakpoint is left lingering, e.g.:
      
       (gdb) PASS: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw off: step in ro region (cannot insert sw break)
       maint info breakpoints 0
       Num     Type           Disp Enb Address    What
       0       sw single-step keep y   0x00400774 in main at [...]/gdb/testsuite/gdb.base/breakpoint-in-ro-region.c:24 inf 1 thread 1
      	 stop only in thread 1
       (gdb) FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw off: single-step breakpoint is not left behind
      
      vs:
      
       (gdb) PASS: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw off: step in ro region (cannot insert sw break)
       maint info breakpoints 0
       No breakpoint or watchpoint matching '0'.
       (gdb) PASS: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw off: single-step breakpoint is not left behind
      
      as at commit d930703d^.
      
      Before commit d930703d, we had a cleanup installed in 'resume'
      that would delete single-step breakpoints on error:
      
        /* Resuming.  */
      
        /* Things to clean up if we QUIT out of resume ().  */
        static void
        resume_cleanups (void *ignore)
        {
          if (!ptid_equal (inferior_ptid, null_ptid))
           delete_single_step_breakpoints (inferior_thread ());
      
          normal_stop ();
        }
      
      That whole function was removed by d930703d mainly to eliminate
      the normal_stop call:
      
      ~~~~
          Note that the exception called from within resume ends up calling
          normal_stop via resume_cleanups.  That's very borked though, because
          normal_stop is going to re-handle whatever was the last reported
          event, possibly even re-running a hook stop...
      ~~~~
      
      But as the regression shows, removing resume_cleanups completely went
      a bit too far, as the delete_single_step_breakpoints call is still
      necessary.
      
      So fix the regression by reinstating the
      delete_single_step_breakpoints call on error.  However, since we're
      trying to eliminate cleanups, restore it in a different form (using
      TRY/CATCH).
      
      Tested on x86-64 GNU/Linux both top of master and on top of a series
      that implements software single-step on x86.
      
      gdb/ChangeLog:
      2018-01-11  Pedro Alves  <palves@redhat.com>
      
      	PR gdb/22583
      	* infrun.c (resume): Rename to ...
      	(resume_1): ... this.
      	(resume): Reimplement as wrapper around resume_1.
      f740fa50
    • Pedro Alves's avatar
      Fix backwards compatibility with old GDBservers (PR remote/22597) · 936a312c
      Pedro Alves authored
      At <https://sourceware.org/ml/gdb-patches/2017-12/msg00285.html>,
      Maciej reported that commit:
      
        commit 5cd63fda
        Date: Wed Oct 4 18:21:10 2017 +0100
        Subject: Fix "Remote 'g' packet reply is too long" problems with multiple inferiors
      
      made GDB stop working with older stubs.  Any attempt to continue
      execution after the initial connection fails with:
      
        [...]
        Process .../gdb/testsuite/outputs/gdb.base/advance/advance created; pid = 2670
        Listening on port 2346
        target remote [...]:2346
        Remote debugging using [...]:2346
        Reading symbols from .../lib64/ld.so.1...done.
        [Switching to Thread <main>]
        (gdb) continue
        Cannot execute this command without a live selected thread.
        (gdb)
      
      The problem is:
      
        (gdb) c
        Cannot execute this command without a live selected thread.
        (gdb) info threads
          Id   Target Id         Frame
          1    Thread 14917      0x00007f341cd98ed0 in _start () from /lib64/ld-linux-x86-64.so.2
      
        The current thread <Thread ID 2> has terminated.  See `help thread'.
      		      ^^^^^^^^^^^
        (gdb)
      
      Note, thread _2_.  There's really only one thread in the inferior
      (it's still at the entry point), but still GDB added a bogus second
      thread.
      
      The reason GDB started adding a second thread after 5cd63fda is
      this hunk:
      
      +                 if (event->ptid == null_ptid)
      +                   {
      +                     const char *thr = strstr (p1 + 1, ";thread:");
      +                     if (thr != NULL)
      +                       event->ptid = read_ptid (thr + strlen (";thread:"),
      +                                                NULL);
      +                     else
      +                       event->ptid = magic_null_ptid;
      +                   }
      
      Note the else branch that falls back to magic_null_ptid.  We reach
      that when we process the initial stop reply sent back in response to
      the the "?" (status) packet early in the connection setup:
      
       Sending packet: $?#3f...Ack
       Packet received: T0506:0000000000000000;07:40a510f4fd7f0000;10:d0fe1201577f0000;
      
      And note that that response does not include a ";thread:XXX" part.
      
      This stop reply is processed after listing threads with qfThreadInfo /
      qsThreadInfo :
      
       Sending packet: $qfThreadInfo#bb...Ack
       Packet received: m3915
       Sending packet: $qsThreadInfo#c8...Ack
       Packet received: l
      
      meaning, when we process that stop reply, we treat the event as coming
      from a thread with ptid == magic_null_ptid, which is not yet in the
      thread list, so we add it then:
      
        (top-gdb) p ptid
        $1 = {m_pid = 42000, m_lwp = -1, m_tid = 1}
        (top-gdb) bt
        #0  0x0000000000840a8c in add_thread_silent(ptid_t) (ptid=...) at src/gdb/thread.c:269
        #1  0x00000000007ad61d in remote_add_thread(ptid_t, int, int) (ptid=..., running=0, executing=0)
            at src/gdb/remote.c:1838
        #2  0x00000000007ad8de in remote_notice_new_inferior(ptid_t, int) (currthread=..., executing=0)
            at src/gdb/remote.c:1921
        #3  0x00000000007b758b in process_stop_reply(stop_reply*, target_waitstatus*) (stop_reply=0x1158860, status=0x7fffffffcc00)
            at src/gdb/remote.c:7217
        #4  0x00000000007b7a38 in remote_wait_as(ptid_t, target_waitstatus*, int) (ptid=..., status=0x7fffffffcc00, options=0)
            at src/gdb/remote.c:7380
        #5  0x00000000007b7cd1 in remote_wait(target_ops*, ptid_t, target_waitstatus*, int) (ops=0x102fac0 <remote_ops>, ptid=..., status=0x7fffffffcc00, options=0) at src/gdb/remote.c:7446
        #6  0x000000000081587b in delegate_wait(target_ops*, ptid_t, target_waitstatus*, int) (self=0x102fac0 <remote_ops>, arg1=..., arg2=0x7fffffffcc00, arg3=0) at src/gdb/target-delegates.c:138
        #7  0x0000000000827d77 in target_wait(ptid_t, target_waitstatus*, int) (ptid=..., status=0x7fffffffcc00, options=0)
            at src/gdb/target.c:2179
        #8  0x0000000000715fda in do_target_wait(ptid_t, target_waitstatus*, int) (ptid=..., status=0x7fffffffcc00, options=0)
            at src/gdb/infrun.c:3589
        #9  0x0000000000716351 in wait_for_inferior() () at src/gdb/infrun.c:3707
        #10 0x0000000000715435 in start_remote(int) (from_tty=1) at src/gdb/infrun.c:3212
      
      things go downhill from this.
      
      We don't see the problem with current master gdbserver, because that
      version always sends the ";thread:" part in the initial stop reply:
      
       Sending packet: $?#3f...Packet received: T0506:0000000000000000;07:a0d4ffffff7f0000;10:d05eddf7ff7f0000;thread:p3cea.3cea;core:3;
      
      Years ago I had added a "--disable-packet=" command line option to
      gdbserver which comes in handy for testing this, since the existing
      "--disable-packet=Tthread" precisely makes gdbserver not send that
      ";thread:" part in stop replies.  The testcase added by this commit
      emulates old gdbserver making use of that.
      
      I've compared a testrun at 5cd63fda^ (before regression) with
      'current master+patch', against old gdbserver at f8b73d13^.  I
      hacked out --once, and "monitor exit" to be able to test.  The results
      are a bit too unstable to tell accurately, but it looked like there
      were no regressions.  Maciej confirmed this worked for him as well.
      
      No regressions on master (against master gdbserver).
      
      gdb/ChangeLog:
      2018-01-11  Pedro Alves  <palves@redhat.com>
      
      	PR remote/22597
      	* remote.c (remote_parse_stop_reply): Default to the last-set
      	general thread instead of to 'magic_null_ptid'.
      
      gdb/testsuite/ChangeLog:
      2018-01-11  Pedro Alves  <palves@redhat.com>
      
      	PR remote/22597
      	* gdb.server/stop-reply-no-thread.c: New file.
      	* gdb.server/stop-reply-no-thread.exp: New file.
      936a312c
    • GDB Administrator's avatar
      Automatic date update in version.in · c03862a3
      GDB Administrator authored
      c03862a3