1. 31 Jan, 2018 1 commit
  2. 27 Jan, 2018 1 commit
    • 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.
      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)
  3. 24 Jan, 2018 1 commit
    • 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
       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
      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
      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.
  4. 22 Jan, 2018 2 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.
      	* MAINTAINERS: Update my company e-mail address.
      	* MAINTAINERS: Update my company e-mail address.
      	* MAINTAINERS: Update my company e-mail address.
      (cherry picked from commit d65ce302)
    • 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))
              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
        (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
      New tests included.
      2018-01-22  Pedro Alves  <palves@redhat.com>
      	    Sergio Durigan Junior  <sergiodj@redhat.com>
      	* typeprint.c (whatis_exp): Initialize "val" in the "whatis type"
      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> &'.
  5. 17 Jan, 2018 3 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)?
      2018-01-17  Sergio Durigan Junior  <sergiodj@redhat.com>
      	* compile/compile.c (compile_to_object): Convert "triplet_rx"
      	to "std::string".
    • 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
          > It should be noted that modifying `configure` to force on
          > `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.
      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.
      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.
    • 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
      (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.
      2018-01-17  Yao Qi  <yao.qi@linaro.org>
      	* aarch64-linux-tdep.c (aarch64_linux_gcc_target_options): New
      	(aarch64_linux_init_abi): Install it to gdbarch hook
  6. 12 Jan, 2018 5 commits
    • 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"
      -- 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:
      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.
      2018-01-12  Andreas Arnez  <arnez@linux.vnet.ibm.com>
      	* infrun.c (keep_going_pass_signal): Clear step-over info when
      	insert_breakpoints fails.
    • Joel Brobecker's avatar
      Bump GDB version number to 8.0.91.DATE-git. · 4d8dd3e1
      Joel Brobecker authored
      	* version.in: Set GDB version number to 8.0.91.DATE-git.
      	* PROBLEMS: Likewise.
    • Joel Brobecker's avatar
      Document the GDB 8.0.91 release in gdb/ChangeLog · 4be8da4b
      Joel Brobecker authored
      	GDB 8.0.91 released.
    • Joel Brobecker's avatar
      Set GDB version number to 8.0.91. · 556dbf30
      Joel Brobecker authored
      	* version.in: Set GDB version number to 8.0.91.
      	* PROBLEMS: Likewise.
    • Joel Brobecker's avatar
      gdb/NEWS: Rename "Changes since 8.0" into "Changes in 8.1". · 93935fd4
      Joel Brobecker authored
              * NEWS: Rename "Changes since 8.0" into "Changes in 8.1".
  7. 11 Jan, 2018 2 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 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
       (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
      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
      Tested on x86-64 GNU/Linux both top of master and on top of a series
      that implements software single-step on x86.
      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.
    • 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.
      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'.
      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
      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).
      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'.
      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.
  8. 10 Jan, 2018 4 commits
    • Pedro Alves's avatar
      language_get_symbol_name_matcher -> get_symbol_name_matcher · a3dc9ae7
      Pedro Alves authored
      Rename language_get_symbol_name_matcher -> get_symbol_name_matcher,
      since the function is no longer a straight "language method".
      2018-01-10  Pedro Alves  <palves@redhat.com>
      	* language.h (language_get_symbol_name_matcher): Rename ...
      	(get_symbol_name_matcher): ... this.
      	* language.c (language_get_symbol_name_matcher): Ditto.
      	* dictionary.c, linespec.c, minsyms.c, psymtab.c, symtab.c: All
      	callers adjusted.
    • Pedro Alves's avatar
      Ada: make verbatim matcher override other language matchers (PR gdb/22670) · 2707f065
      Pedro Alves authored
      A previous patch fixed verbatim matching in the lookup at the minimal
      symbol level, but we should also be finding that same symbol through
      the partial/full symtab search.
      For example, this is what happens if we use "print" instead of
          (gdb) p <MixedCaseFunc>
          $1 = {<text variable, no debug info>} 0x4024dc <MixedCaseFunc>
      Before the C++ wildmatching series, GDB knows that MixedCaseFunc is a
      function without parameters, and the expression above means calling
      it.  If you try it before having started the inferior, you'd get the
      following (expected) error:
          (gdb) print  <MixedCaseFunc>
          You can't do that without a process to debug.
      The main idea behind making the name matcher be determined by the
      symbol's language is so that C++ (etc.) wildmatching in linespecs
      works even if the current language is not C++, as e.g., when you step
      through C or assembly code.
      Ada's verbatim matching syntax however ("<...>") isn't quite the same.
      It is more a property of the current language than of a particular
      symbol's language.  We want to support this syntax when debugging an
      Ada program, but it's reason of existence is to find non-Ada symbols.
      This suggests going back to enabling it depending on current language
      instead of language of the symbol being matched.
      I'm not entirely happy with the "current_language" reference (though I
      think that it's harmless).  I think we could try storing the current
      language in the lookup_name_info object, and then convert a bunch of
      functions more to pass around lookup_name_info objects instead of
      "const char *" names.  I.e., build the lookup_name_info higher up.
      I'm not sure about that, I'll have to think more about it.  Maybe
      something different will be better.  Meanwhile, this gets us going.
      I've extended the testcase to also exercise a no-debug-info function,
      for extra coverage of the minsyms-only paths.
      2018-01-10  Pedro Alves  <palves@redhat.com>
      	PR gdb/22670
      	* dwarf2read.c
      	Adjust to use language_get_symbol_name_matcher instead of
      	* language.c (language_get_symbol_name_matcher): If in Ada mode
      	and the lookup name is a verbatim match, return Ada's matcher.
      	* language.h (language_get_symbol_name_matcher): Adjust comment.
      	(ada_lookup_name_info::verbatim_p):: New method.
      2018-01-10  Pedro Alves  <palves@redhat.com>
      	PR gdb/22670
      	* gdb.ada/bp_c_mixed_case.exp: Add intro comment.  Test printing C
      	functions too.  Test setting breakpoints and printing C functions
      	with no debug info too.
      	* gdb.ada/bp_c_mixed_case/qux.c: New file.
    • Pedro Alves's avatar
      Fix gdb.ada/complete.exp's "complete break ada" test (PR gdb/22670) · be1f9aab
      Pedro Alves authored
      This patch fixes the regression covered by the test added by:
          commit 344420da
          Date: Thu Jan 4 03:30:37 2018 -0500
          Subject: Add "complete break ada" test to gdb.ada/complete.exp
      The regression had been introduced by:
          commit b5ec771e
          Date:   Wed Nov 8 14:22:32 2017 +0000
          Subject: Introduce lookup_name_info and generalize Ada's FULL/WILD name matching
      The gist of it is that linespec completion in Ada mode is generating
      additional matches that should not appear in the match list
      (internally generated symbols, or symbols that should be enclosed
      between "<...>").  These extraneous entries have uppercase characters, such as:
          break ada__stringsS
          break ada__strings__R11s
      These matches come from minimal symbols.  The problem is that Ada
      minsyms end up with no language set (language_auto), and thus we end
      up using the generic symbol name matcher for those instead of Ada's.
      We already had a special case for in compare_symbol_name to handle
      this, but it was limited to expressions, while the case at hand is
      completing a linespec.  Fix this by applying the special case to
      linespec completion as well.  I.e., remove the EXPRESSION check from
      compare_symbol_name.  That alone turns out to not be sufficient still
      -- GDB would still show a couple entries that shouldn't be there:
          break ada__exceptions__exception_data__append_info_exception_name__2Xn
          break ada__exceptions__exception_data__exception_name_length__2Xn
      The reason is that these minimal symbols end up with their language
      set to language_cplus / C++, because those encoded names manage to
      demangle successfully as C++ symbols (using an old C++ mangling
        $ echo ada__exceptions__exception_data__append_info_exception_name__2Xn | c++filt
      It's unfortunate that Ada's encoding scheme doesn't start with some
      unique prefix like "_Z" in the C++ Itanium ABI mangling scheme.  For
      now, paper over that by treating C++ minsyms as Ada minsyms.
      2018-01-10  Pedro Alves  <palves@redhat.com>
              PR gdb/22670
      	* ada-lang.c (ada_collect_symbol_completion_matches): If the
      	minsym's language is language_auto or language_cplus, pass down
      	language_ada instead.
      	* symtab.c (compare_symbol_name): Don't frob symbol language here.
      2018-01-10  Pedro Alves  <palves@redhat.com>
              PR gdb/22670
      	* gdb.ada/complete.exp ("complete break ada"): Replace kfail with
      	a fail.
    • Pedro Alves's avatar
      Fix gdb.ada/bp_c_mixed_case.exp (PR gdb/22670) · bd140f1f
      Pedro Alves authored
      The problem here is that we are using the user-provided lookup name
      literally for name comparisons.  I.e., "<MixedCase>" with the "<>"s
      This commit fixes the minsym lookup case.  psymbol/symbol lookup will
      be fixed in a follow up.
      In the minsym case, we're using using the user-provided lookup name
      literally for linkage name comparisons.  That obviously can't work
      since the "<>" are not really part of the linkage name.
      The original idea was that we'd use the symbol's language to select
      the right symbol name matching algorithm, but that doesn't work for
      Ada because it's not really possible to unambiguously tell from the
      linkage name alone whether we're dealing with Ada symbols, so Ada
      minsyms end up with no language set, or sometimes C++ set.
      So fix this by treating Ada mode specially when determining the
      linkage name to match against.
      2018-01-10  Pedro Alves  <palves@redhat.com>
      	PR gdb/22670
      	* minsyms.c (linkage_name_str): New function.
      	(iterate_over_minimal_symbols): Use it.
      2018-01-10  Pedro Alves  <palves@redhat.com>
      	PR gdb/22670
      	* gdb.ada/bp_c_mixed_case.exp: Remove setup_kfail calls.
  9. 08 Jan, 2018 2 commits
    • Samuel Thibault's avatar
      hurd: Add enough auxv support for AT_ENTRY for PIE binaries · d31fecf3
      Samuel Thibault authored
      Add PIE support for hurd, by faking an AT_ENTRY auxv entry.  That value
      is expected to be read by svr4_exec_displacement, which will propagate
      the executable displacement.
      	* gdb/gnu-nat.c: Include <elf.h> and <link.h>.
      	(gnu_xfer_auxv): New function.
      	(gnu_xfer_partial): Call gnu_xfer_auxv when `object' is
    • Yao Qi's avatar
      Fix GDB build failure when $development is false · 6caf4baa
      Yao Qi authored
      We don't build GDB selftests bits when $development is false.  However, if
      we turn bfd/development.sh:$development to false, common/selftest.c is
      compiled which is not expected.  It causes the build failure,
      selftest.o: In function `selftests::run_tests(char const*)':
      binutils-gdb/gdb/common/selftest.c:97: undefined reference to `selftests::reset()'
      collect2: error: ld returned 1 exit status
      I fix this issue by putting selftest.o selftest-arch.o into CONFIG_OBS
      only when $development is true.  After this is fixed, there are other
      build failures in maint.c, this patch fixes them as well.
      In the release mode, the output of these commands are:
      (gdb) maintenance selftest
      Selftests are not available in a non-development build.
      (gdb) maintenance selftest foo
      Selftests are not available in a non-development build.
      (gdb) maintenance info selftests
      Selftests are not available in a non-development build.
      2018-01-08  Yao Qi  <yao.qi@linaro.org>
      	    Simon Marchi  <simon.marchi@ericsson.com>
      	* Makefile.in (COMMON_SFILES): Remove selftest-arch.c and
      	(COMMON_OBS): Remove selftest.o.
      	* configure.ac: Append selftest-arch.c and common/selftest.c to
      	CONFIG_SRCS.  Append selftest-arch.o and selftest.o to COMMON_OBS.
      	* configure: Re-generated.
      	* maint.c (maintenance_selftest): Wrap selftests::run_tests with
      	(maintenance_info_selftests): Likewise.
      2018-01-08  Simon Marchi  <simon.marchi@ericsson.com>
      	* gdb.gdb/unittest.exp: Match output in non-development mode.
  10. 05 Jan, 2018 5 commits
    • Pedro Alves's avatar
      Fix regression: cannot start with LD_PRELOAD=libSegFault.so (PR gdb/18653#c7) · 1ec6a114
      Pedro Alves authored
      At https://sourceware.org/bugzilla/show_bug.cgi?id=18653#c7, Andrew
      reports that the fix for PR gdb/18653 made GDB useless if you preload
      libSegFault.so, because GDB internal-errors on startup:
       $ LD_PRELOAD=libSegFault.so gdb
       src/gdb/common/signals-state-save-restore.c:64: internal-error: unexpected signal handler
       A problem internal to GDB has been detected,
       further debugging may prove unreliable.
       Aborted (core dumped)
      The internal error comes from the code saving the signal dispositions
      inherited from gdb's parent:
       (top-gdb) bt
       #0  0x000000000056b001 in internal_error(char const*, int, char const*, ...) (file=0xaf5f38 "src/gdb/common/signals-state-save-restore.c", line=64, fmt=0xaf5f18 "unexpected signal handler") at src/gdb/common/errors.c:54
       #1  0x00000000005752c9 in save_original_signals_state() () at src/gdb/common/signals-state-save-restore.c:64
       #2  0x00000000007425de in captured_main_1(captured_main_args*) (context=0x7fffffffd860)
           at src/gdb/main.c:509
       #3  0x0000000000743622 in captured_main(void*) (data=0x7fffffffd860) at src/gdb/main.c:1145
       During symbol reading, cannot get low and high bounds for subprogram DIE at 24065.
       #4  0x00000000007436f9 in gdb_main(captured_main_args*) (args=0x7fffffffd860) at src/gdb/main.c:1171
       #5  0x0000000000413acd in main(int, char**) (argc=1, argv=0x7fffffffd968) at src/gdb/gdb.c:32
      This commit downgrades the internal error to a warning.  You'll get
       $ LD_PRELOAD=libSegFault.so gdb
       warning: Found custom handler for signal 11 (Segmentation fault) preinstalled.
       Some signal dispositions inherited from the environment (SIG_DFL/SIG_IGN)
       won't be propagated to spawned programs.
       GNU gdb (GDB)
       Copyright (C) 2017 Free Software Foundation, Inc.
       License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
       This is free software: you are free to change and redistribute it.
       There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
       and "show warranty" for details.
       This GDB was configured as "x86_64-pc-linux-gnu".
       Type "show configuration" for configuration details.
       For bug reporting instructions, please see:
       Find the GDB manual and other documentation resources online at:
       For help, type "help".
       Type "apropos word" to search for commands related to "word"...
      This also moves the location where save_original_signals_state is
      called a bit further below (to after option processing), so that "-q"
      disables the warning:
       $ LD_PRELOAD=libSegFault.so gdb -q
      New testcase included.
      2018-01-05  Pedro Alves  <palves@redhat.com>
      	PR gdb/18653
      	* common/signals-state-save-restore.c
      	(save_original_signals_state): New parameter 'quiet'.  Warn if we
      	find a custom handler preinstalled, instead of internal erroring.
      	But only warn if !quiet.
      	* common/signals-state-save-restore.h
      	(save_original_signals_state): New parameter 'quiet'.
      	* main.c (captured_main_1): Move save_original_signals_state call
      	after option handling, and pass QUIET.
      2018-01-05  Pedro Alves  <palves@redhat.com>
      	PR gdb/18653
      	* server.c (captured_main): Pass quiet=false to
      2018-01-05  Pedro Alves  <palves@redhat.com>
      	PR gdb/18653
      	* gdb.base/libsegfault.exp: New.
    • Pedro Alves's avatar
      Fix gdb/spu-tdep.c build breakage · 1dc9069e
      Pedro Alves authored
      Commit de63c46b ("Fix regresssion(internal-error) printing
      subprogram argument (PR gdb/22670)") missed updating spu-tdep.c for
      the block_lookup_symbol interface change, resulting in:
        ../../binutils-gdb/gdb/spu-tdep.c: In function void spu_catch_start(objfile*):
        ../../binutils-gdb/gdb/spu-tdep.c:1969:59: error: cannot convert domain_enum_tag to symbol_name_match_type for argument 3 to symbol* block_lookup_symbol(const block*, const char*, symbol_name_match_type, domain_enum)
      	 sym = block_lookup_symbol (block, "main", VAR_DOMAIN);
      2018-01-05  Pedro Alves  <palves@redhat.com>
      	* spu-tdep.c (spu_catch_start): Pass
      	symbol_name_match_type::SEARCH_NAME to block_lookup_symbol.
    • Pedro Alves's avatar
      Fix regresssion(internal-error) printing subprogram argument (PR gdb/22670) · a76cf1f4
      Pedro Alves authored
      At <https://sourceware.org/ml/gdb-patches/2017-12/msg00298.html>, Joel
      Consider the following code which first declares a tagged type (the
      equivalent of a class in Ada), and then a procedure which takes a
      pointer (access) to this type's 'Class.
          package Pck is
             type Top_T is tagged record
                N : Integer := 1;
             end record;
             procedure Inspect (Obj: access Top_T'Class);
          end Pck;
      Putting a breakpoint in that procedure and then running to it triggers
      an internal error:
          (gdb) break inspect
          (gdb) continue
          Breakpoint 1, pck.inspect (obj=0x63e010
          /[...]/gdb/stack.c:621: internal-error: void print_frame_args(symbol*, frame_info*, int, ui_file*): Assertion `nsym != NULL' failed.
      What's special about this subprogram is that it takes an access to
      what we call a 'Class type, and for implementation reasons, the
      compiler adds an extra argument named "objL". If you are curious why,
      it allows the compiler for perform dynamic accessibility checks that
      are mandated by the language.
      If we look at the location where we get the internal error (in
      stack.c), we find that we are looping over the symbol of each
      parameter, and for each parameter, we do:
          /* We have to look up the symbol because arguments can have
             two entries (one a parameter, one a local) and the one we
             want is the local, which lookup_symbol will find for us.
              nsym = lookup_symbol (SYMBOL_LINKAGE_NAME (sym),
                                    b, VAR_DOMAIN, NULL).symbol;
              gdb_assert (nsym != NULL);
      The lookup_symbol goes through the lookup structure, which means the
      symbol's linkage name ("objL") gets transformed into a
      lookup_name_info object (in block_lookup_symbol), before it gets fed
      to the block symbol dictionary iterators.  This, in turn, triggers the
      symbol matching by comparing the "lookup" name which, for Ada, means
      among other things, lowercasing the given name to "objl".  It is this
      transformation that causes the lookup find no matches, and therefore
      trip this assertion.
      Going back to the "offending" call to lookup_symbol in stack.c, what
      we are trying to do, here, is do a lookup by linkage name.  So, I
      think what we mean to be doing is a completely literal symbol lookup,
      so maybe not even strcmp_iw, but actually just plain strcmp???
      In the past, in practice, you could get that effect by doing a lookup
      using the C language. But that doesn't work, because we still end up
      somehow using Ada's lookup_name routine which transforms "objL".
      So, ideally, as I hinted before, I think what we need is a way to
      perform a literal lookup so that searches by linkage names like the
      above can be performed.
      This commit fixes the problem by implementing something similar to
      Joel's literal idea, but with some important differences.
      I considered adding a symbol_name_match_type::LINKAGE and supporting
      searching by linkage name for any language, but the problem with that
      is that the dictionaries only work with SYMBOL_SEARCH_NAME, because
      that's what is used for hashing.  We'd need separate dictionaries for
      hashed linkage names.
      So with the current symbol tables infrastructure, it's not literal
      linkage names that we want to pass down, but instead literal _search_
      names (SYMBOL_SEARCH_NAME, etc.).
      However, psymbols have no overload/function parameter info in C++, so
      a straight strcmp doesn't work properly for C++ name matching.
      So what we do is be a little less aggressive then and add a new
      symbol_name_match_type::SEARCH_SYMBOL instead that takes as input a
      non-user-input search symbol, and then we skip any decoding/demangling
      steps and make:
       - Ada treat that as a verbatim match,
       - other languages treat it as symbol_name_match_type::FULL.
      This also fixes the new '"maint check-psymtabs" for Ada' testcase for
      me (gdb.ada/maint_with_ada.exp).  I've not removed the kfail yet
      because Joel still sees that testcase failing with this patch.
      That'll be fixed in follow up patches.
      2018-01-05  Pedro Alves  <palves@redhat.com>
      	PR gdb/22670
      	* ada-lang.c (literal_symbol_name_matcher): New function.
      	(ada_get_symbol_name_matcher): Use it for
      	* block.c (block_lookup_symbol): New parameter 'match_type'.  Pass
      	it down instead of assuming symbol_name_match_type::FULL.
      	* block.h (block_lookup_symbol): New parameter 'match_type'.
      	* c-valprint.c (print_unpacked_pointer): Use
      	lookup_symbol_search_name instead of lookup_symbol.
      	* compile/compile-object-load.c (get_out_value_type): Pass down
      	* cp-namespace.c (cp_basic_lookup_symbol): Pass down
      	* cp-support.c (cp_get_symbol_name_matcher): Handle
      	* infrun.c (insert_exception_resume_breakpoint): Use
      	* p-valprint.c (pascal_val_print): Use lookup_symbol_search_name.
      	* psymtab.c (maintenance_check_psymtabs): Use
      	symbol_name_match_type::SEARCH_NAME and SYMBOL_SEARCH_NAME.
      	* stack.c (print_frame_args): Use lookup_symbol_search_name and
      	* symtab.c (lookup_local_symbol): Don't demangle the lookup name
      	if symbol_name_match_type::SEARCH_NAME.
      	(lookup_symbol_in_language): Pass down
      	(lookup_symbol_search_name): New.
      	(lookup_language_this): Pass down
      	(lookup_symbol_aux, lookup_local_symbol): New parameter
      	'match_type'.  Pass it down.
      	* symtab.h (symbol_name_match_type::SEARCH_NAME): New enumerator.
      	(lookup_symbol_search_name): New declaration.
      	(lookup_symbol_in_block): New 'match_type' parameter.
      2018-01-05  Joel Brobecker  <brobecker@adacore.com>
      	PR gdb/22670
      	* gdb.ada/access_tagged_param.exp: New file.
      	* gdb.ada/access_tagged_param/foo.adb: New file.
    • Pedro Alves's avatar
      Fix gdb.ada/info_addr_mixed_case.exp (PR gdb/22670) · 7a19098f
      Pedro Alves authored
      The comments about mixed case in the testcase are actually a red
      herring.  The problem here is that we'd get to
      ada_lookup_encoded_symbol with "my_table", which wraps the looked up
      name in "<>"s to force a verbatim match, and that in turn disables
      wild matching.
      Fix this by swapping around the internals of ada_lookup_encoded_symbol
      and ada_lookup_symbol, thus avoiding the encoding and
      verbatim-wrapping in the ada_lookup_symbol case, the case that starts
      with a user-provided lookup name.
      Ada encoding is still done of course, in the ada_lookup_name_info
      ctor.  This could be also seen as avoiding the double-encoding problem
      in a different way.
      2018-01-05  Pedro Alves  <palves@redhat.com>
      	PR gdb/22670
      	* ada-lang.c (ada_lookup_encoded_symbol): Reimplement in terms of
      	(ada_lookup_symbol): Reimplement in terms of
      	ada_lookup_symbol_list, bits factored out from
      2018-01-05  Pedro Alves  <palves@redhat.com>
      	PR gdb/22670
      	* gdb.ada/info_addr_mixed_case.exp: Remove kfail.  Extend test to
      	exercise lower case too, and to exercise both full matching and
      	wild matching.
    • Joel Brobecker's avatar
      Bump version to 8.0.90.DATE-git. · db52f3d0
      Joel Brobecker authored
      Now that the GDB 8.1 branch has been created, we can
      bump the version number.
      	GDB 8.1 branch created (5219ac62):
      	* version.in: Bump version to 8.0.90.DATE-git.
  11. 03 Jan, 2018 1 commit
    • Xavier Roirand's avatar
      (Ada) New command to stop at start of exception handler. · 9f757bf7
      Xavier Roirand authored
      When using gdb for debugging Ada source code, there are several catchpoint
      types you can define in order to stop upon certain conditions.  Let's
      use this small example:
      procedure Foo is
            raise Constraint_Error;
            when Program_Error =>
            when Constraint_Error =>
            when others =>
      end Foo;
      One can stop when the exception is being raised by using the exception
      catchpoint like below:
      (gdb) catch exception
      Catchpoint 1: all Ada exceptions
      In that case, when running Foo, gdb will stop at the line where the exception
      was raised:
      >>>   raise Constraint_Error;
      This patch introduces new type of catchpoint, when the user wants to stop
      at the location of the exception handling.
      Imagine we want to stop on any exception handled by the program, we can do:
      (gdb) catch handlers
      Catchpoint 1: all Ada exceptions handlers
      (gdb) r
      Starting program: /tmp/foo
      By doing so, when running Foo, gdb will stop here:
      Catchpoint 1, exception at 0x000000000040255a in foo () at foo.adb:25
      25          when Constraint_Error =>
      It is also possible to stop when the Constraint_Error exception is being
      handled in this program.  With this patch, we can use:
      (gdb) catch handlers Constraint_Error
      Catchpoint 1: `Constraint_Error' Ada exception handlers
      Like for other catchpoint, you can set a condition when adding a catchpoint
      on exception handlers.
      Here the handlers catchpoint checks Global_Var:
      (gdb) catch handlers Constraint_Error if Global_Var /= 0
              * ada-lang.h (ada_exception_catchpoint_kind) <ada_catch_handlers>:
              Add field.
              * ada-lang.c (struct exception_support_info) <catch_handlers_sym>:
              Add field.
              (default_exception_support_info) <catch_handlers_sym>: Add field.
              (exception_support_info_fallback) <catch_handlers_sym>: Add field.
              (ada_exception_name_addr_1): Add "catch handlers" handling.
              (ada_exception_catchpoint_cond_string) <ex>: New parameter.
              Update all callers.
              (create_excep_cond_exprs) <ex>: Add parameter.
              (re_set_exception): Update create_excep_cond_exprs call.
              (print_it_exception, print_one_exception, print_mention_exception)
              (print_recreate_exception): Add "catch handler" handling.
              (allocate_location_catch_handlers, re_set_catch_handlers)
              (check_status_catch_handlers, print_it_catch_handlers)
              (print_one_catch_handlers, print_mention_catch_handlers)
              (print_recreate_catch_handlers): New function.
              (catch_handlers_breakpoint_ops): New variable.
              (catch_ada_exception_command_split) <is_catch_handlers_cmd>:
              Add parameter.  Add "catch handler" handling.
              (ada_exception_sym_name, ada_exception_breakpoint_ops):
              Add "catch handler" handling.
              (ada_exception_catchpoint_cond_string): Add "catch handler"
              (create_ada_exception_catchpoint): Update create_excep_cond_exprs
              (catch_ada_handlers_command): New function.
              (initialize_ada_catchpoint_ops): Initialize "catch handlers"
              operations structure.
              (_initialize_ada_language): Add "catch handlers" command entry.
              * NEWS: Document "catch handlers" feature.
              * gdb.texinfo (Set Catchpoints): Add documentation for new
              "catch handlers" action.
              * gdb.ada/excep_handle.exp: New testcase.
              * gdb.ada/excep_handle/foo.adb: New file.
              * gdb.ada/excep_handle/pck.ads: New file.
      Tested on x86_64-linux.
  12. 02 Jan, 2018 8 commits
    • Joel Brobecker's avatar
      [gdb/Ada] slices of arrays with dynamic strides · 9fe561ab
      Joel Brobecker authored
          Consider the following Ada code:
             procedure Nested (L, U : Integer) is
                subtype Small_Type is Integer range L .. U;
                type Record_Type (I : Small_Type := L) is record
                   S : String (1 .. I);
                end record;
                type Array_Type is array (Integer range <>) of Record_Type;
                A1 : Array_Type :=
                  (1 => (I => 0, S => <>),
                   2 => (I => 1, S => "A"),
                   3 => (I => 2, S => "AB"));
                procedure Discard (R : Record_Type) is
                end Discard;
                Discard (A1 (1));  -- STOP
      Trying to print a slice of that array currently yields:
          (gdb) p a1(1..3)
          $1 = ((i => 0, s => ""), (i => 0, s => ""), (i => 0, s => ""))
      We expected instead:
          (gdb) p a1(1..3)
          $1 = ((i => 0, s => ""), (i => 1, s => "A"), (i => 2, s => "AB"))
      This is because the functions we use in ada-lang.c to create the type
      of the array slice (ada_value_slice and ada_value_slice_from_ptr) was
      not taking into account the stride of the array. This patch fixes this.
              * ada-lang.c (ada_value_slice_from_ptr): Take array stride into
              account when creating the array type of the slice.
              (ada_value_slice): Likewise.
              * gdb.ada/dyn_stride.exp: Add slice test.
      Note that, with the current use of ada_value_slice, the enhancement
      to handle dynamic array strides seems unnecessary, because I do not
      see how an array with a dynamic stride can be referenced by either
      by reference or pointer. Since references are coerced to array pointers,
      in both cases, the slice is performed by ada_value_slice_from_ptr.
      But ada_value_slice is enhanced nonetheless, in the spirit of making
      the code more robust, in case we missed something, and also as similar
      as possible with its from_ptr counterpart.
      tested on x86_64-linux.
    • Joel Brobecker's avatar
      Add support for dynamic DW_AT_byte_stride. · a405673c
      Joel Brobecker authored
      This patch adds support for DW_AT_byte_stride, using Ada as one
      example of where this would be useful. However, the implementation
      is language-agnostic.
      Consider the following Ada code:
         procedure Nested (L, U : Integer) is
            subtype Small_Type is Integer range L .. U;
            type Record_Type (I : Small_Type := L) is record
               S : String (1 .. I);
            end record;
            type Array_Type is array (Integer range <>) of Record_Type;
            A1 : Array_Type :=
              (1 => (I => 0, S => <>),
               2 => (I => 1, S => "A"),
               3 => (I => 2, S => "AB"));
            procedure Discard (R : Record_Type) is
            end Discard;
            Discard (A1 (1));  -- STOP
      It defines an array A1 of Record_Type, which is a variant record
      type whose maximum size actually depends on the value of the
      parameters passed when calling Nested. As a result, the stride
      of the array A1 cannot be known statically, which leads the compiler
      to generate a dynamic DW_AT_byte_stride attribute for our type.
      Here is what the debugging info looks like with GNAT:
              .uleb128 0x10   # (DIE (0x14e) DW_TAG_array_type)
              .long   .LASF17 # DW_AT_name: "foo__nested__T18b"
              .long   0x141   # DW_AT_byte_stride
              .long   0xdc    # DW_AT_type
              .uleb128 0x11   # (DIE (0x15f) DW_TAG_subrange_type)
              .long   0x166   # DW_AT_type
              .byte   0x3     # DW_AT_upper_bound
              .byte   0       # end of children of DIE 0x14e
      There DW_AT_byte_stride is a reference to a local (internal)
              .uleb128 0x9    # (DIE (0x141) DW_TAG_variable)
              .long   .LASF6  # DW_AT_name: "foo__nested__T18b___PAD___XVZ"
      This patch enhances GDB to handle this dynamic byte stride attribute
      by first adding a new dynamic_prop_node_kind (DYN_PROP_BYTE_STRIDE)
      to store the array dynamic stride info (when dynamic). It then enhances
      the dynamic type resolver to handle this dynamic property.
      Before applying this patch, trying to print the value of some of
      A1's elements after having stopped at the "STOP" comment does not
      work. For instance:
          (gdb) p a1(2)
          Cannot access memory at address 0x80000268dec0
      With this patch applied, GDB now prints the value of all 3 elements
          (gdb) print A1(1)
          $1 = (i => 0, s => "")
          (gdb) print A1(2)
          $2 = (i => 1, s => "A")
          (gdb) print A1(3)
          $3 = (i => 2, s => "AB")
              * gdbtypes.h (enum dynamic_prop_node_kind) <DYN_PROP_BYTE_STRIDE>:
              New enum value.
              (create_array_type_with_stride): Add byte_stride_prop parameter.
              * gdbtypes.c (create_array_type_with_stride) <byte_stride_prop>:
              New parameter.  Update all callers in this file.
              (array_type_has_dynamic_stride): New function.
              (is_dynamic_type_internal, resolve_dynamic_array): Add handling
              of arrays with dynamic byte strides.
              * dwarf2read.c (read_array_type): Add support for dynamic
              DW_AT_byte_stride attributes.
              * gdb.ada/dyn_stride: New testcase.
      Tested on x86_64-linux.
    • Joel Brobecker's avatar
      treat Ada DW_TAG_unspecified_type DIEs as stub types · 74a2f8ff
      Joel Brobecker authored
      Consider the gdb.ada/taft_type.exp testcase, which exercises
      the situation where a variable is defined using a type which
      is a pointer to an incomplete type, with the actual type
      definition being provided by another unit. Up to now, the
      strategy used by GNAT when generating the DWARF debugging info
      was to produce a incomplete DW_TAG_enumeration_type DIE with
      a DW_AT_declaration flag attached to it:
              .uleb128 0x4    # (DIE (0x3e) DW_TAG_enumeration_type)
              .long   .LASF4  # DW_AT_name: "pck__empty"
                              # DW_AT_declaration
      However, a more standard way for the compiler to describe
      this kind of type is to use the DW_TAG_unspecified_type tag.
      When the compiler is enhanced to do so, we'll need to treat
      such types as stubs -- we only do so with types from Ada units,
      however, as the meaning of this TAG is intentionally left
      permissive and language-specific by the DWARF standard.
      Without this patch, running the testcase above with an enhanced
      compiler now yields:
          (gdb) print w.e.all
          Attempt to dereference a generic pointer.
          FAIL: gdb.ada/taft_type.exp: print w.e.all
      	* dwarf2read.c (read_unspecified_type): Treat
              DW_TAG_enumeration_type DIEs from Ada units as stubs.
      Tested on x86_64-linux, fixes the FAIL in gdb.ada/taft_type.exp above.
    • Joel Brobecker's avatar
      Update copyright year range in all GDB files · e2882c85
      Joel Brobecker authored
              Update copyright year range in all GDB files
    • Joel Brobecker's avatar
      gdb/copyright.py: Remove testsuite/gdb.base/step-line.{c,inp} special handling · 1690bb24
      Joel Brobecker authored
      In the past, these files needed to be handled by hand, because
      the testcase was sensitive to the length of the header, which was
      potentially changing when new copyright years were added to
      the copyright header. Now that we simply maintain and update
      a range, the length of the copyright header should not change
      as a consequence of the update performed by this script, so
      special handling of those files is no longer necessary.
              * copyright.py (BY_HAND): Remove gdb/testsuite/gdb.base/step-line.inp
              and gdb/testsuite/gdb.base/step-line.c.
    • Joel Brobecker's avatar
      gdb/copyright.py: Do not forget to remind about MULTIPLE_COPYRIGHT_HEADERS · 0f0c98a8
      Joel Brobecker authored
      There is a small logical error in the part of the script that
      dumps the list of files in BY_HAND + MULTIPLE_COPYRIGHT_HEADERS
      but only checkis the contents of BY_HAND. The issue becomes
      apparent as soon as BY_HAND is empty. Prevent this from happening
      by treating the two lists separately, as this allows us to provide
      a more informative message in the case of MULTIPLE_COPYRIGHT_HEADERS.
              * copyright.py (main): Dump the contents of
              MULTIPLE_COPYRIGHT_HEADERS (separately) from BY_HAND,
              even if BY_HAND is empty.
    • Joel Brobecker's avatar
      Update copyright year in version message of GDB, GDBserver and GDBreplay · 82e1e79a
      Joel Brobecker authored
      	* top.c (print_gdb_version): Update Copyright year in version
      	* gdbreplay.c (gdbreplay_version): Update copyright year in
      	version message.
      	* server.c (gdbserver_version): Likewise.
    • Joel Brobecker's avatar
      Yearly rotation of the gdb/ChangeLog file · 053f54e5
      Joel Brobecker authored
              * config/djgpp/fnchange.lst: Add entry for gdb/ChangeLog-2017.
  13. 31 Dec, 2017 4 commits
    • Ruslan Kabatsayev's avatar
      Avoid indexing std::vector past the end · 47fea877
      Ruslan Kabatsayev authored
      The code here wants to find address of an element, and often this
      element is one past the end of std::vector. Dereferencing that element
      leads to undefined behavior, so it's better to simply use pointer
      arithmetic instead of taking address of invalid dereference.
      	* psymtab.c (recursively_search_psymtabs): Use pointer arithmetic
      	instead of dereferencing std::vector past the end.
    • Simon Marchi's avatar
      Only ignore -Wenum-compare-switch if it exists · cfa27c39
      Simon Marchi authored
      My patch
        dwarf2read: Silence -Wenum-compare-switch warning
      made some parts of dwarf2read.c ignore warnings about switch using enums
      of different kinds.  What I did not realize was that older Clang
      versions (prior to 6) did not have that warning, and therefore give this
      /home/emaisin/src/binutils-gdb/gdb/dwarf2read.c:24187:7: error: unknown warning group '-Wenum-compare-switch', ignored [-Werror,-Wunknown-pragmas]
      /home/emaisin/src/binutils-gdb/gdb/common/diagnostics.h:42:3: note: expanded from macro 'DIAGNOSTIC_IGNORE_SWITCH_DIFFERENT_ENUM_TYPES'
        DIAGNOSTIC_IGNORE ("-Wenum-compare-switch")
      /home/emaisin/src/binutils-gdb/gdb/common/diagnostics.h:27:3: note: expanded from macro 'DIAGNOSTIC_IGNORE'
        _Pragma (STRINGIFY (GCC diagnostic ignored option))
      <scratch space>:10:25: note: expanded from here
       GCC diagnostic ignored "-Wenum-compare-switch"
      Clang has a way to test if it knows about a particular warning.  This
      patch uses that feature to only define
      warning is recognized by the Clang version being used.  I tested
      building dwarf2read.c with clang 4, 5, 6, as well as gcc.
      	* common/diagnostics.h
      	define if the compiler knows about -Wenum-compare-switch.
    • Simon Marchi's avatar
      dwarf2read: Silence -Wenum-compare-switch warning · 132448f8
      Simon Marchi authored
      Compiling with Clang 6 gives:
      /home/emaisin/src/binutils-gdb/gdb/dwarf2read.c:24385:14: error: comparison of two values with different enumeration types in switch statement ('enum dwarf_macro_record_type' and 'dwarf_macinfo_record_type') [-Werror,-Wenum-compare-switch]
              case DW_MACINFO_vendor_ext:
      /home/emaisin/src/binutils-gdb/gdb/dwarf2read.c:24561:7: error: comparison of two values with different enumeration types in switch statement ('enum dwarf_macro_record_type' and 'dwarf_macinfo_record_type') [-Werror,-Wenum-compare-switch]
              case DW_MACINFO_vendor_ext:
      This code uses the two enum types on purpose, because it handles both
      .debug_macro and .debug_macinfo sections.  Add some pragmas to disable
      the warning in these specific cases.
      	* dwarf2read.c (dwarf_decode_macro_bytes): Ignore
      	-Wenum-compare-switch warning.
      	(dwarf_decode_macros): Likewise.
    • Tom Tromey's avatar
      C++-ify parser_state · e9d9f57e
      Tom Tromey authored
      This mildly C++-ifies parser_state and stap_parse_info -- just enough
      to remove some cleanups.
      This version includes the changes implemented by Simon.
      Regression tested by the buildbot.
      2017-12-30  Tom Tromey  <tom@tromey.com>
      	    Simon Marchi  <simon.marchi@ericsson.com>
      	* stap-probe.h (struct stap_parse_info): Add constructor,
      	* stap-probe.c (stap_parse_argument): Update.
      	* rust-exp.y (rust_lex_tests): Update.
      	* parser-defs.h (struct parser_state): Add constructor,
      	destructor, release method.
      	<expout>: Change type to expression_up.
      	(null_post_parser): Change type.
      	(initialize_expout, reallocate_expout): Remove.
      	* parse.c (parser_state::parser_state): Rename from
      	(parser_state::release): Rename from reallocate_expout.
      	(write_exp_elt, parse_exp_in_context_1, increase_expout_size):
      	(null_post_parser): Change type of "exp".
      	* dtrace-probe.c (dtrace_probe::build_arg_exprs): Update.
      	* ada-lang.c (resolve, resolve_subexp)
      	(replace_operator_with_call): Change type of "expp".
      	* language.h (struct language_defn) <la_post_parser>: Change type
      	of "expp".
  14. 30 Dec, 2017 1 commit
    • Simon Marchi's avatar
      Make mapped_debug_names and mapped_index final · fc898b42
      Simon Marchi authored
      When compiling with Clang 6, I see these warnings:
      /home/emaisin/src/binutils-gdb/gdb/dwarf2read.c:25421:5: error: destructor called on non-final 'mapped_index' that has virtual functions but non-virtual destructor [-Werror,-Wdelete-non-virtual-dtor]
          data->index_table->~mapped_index ();
      In file included from /home/emaisin/src/binutils-gdb/gdb/dwarf2read.c:31:
      In file included from /home/emaisin/src/binutils-gdb/gdb/defs.h:28:
      In file included from /home/emaisin/src/binutils-gdb/gdb/common/common-defs.h:92:
      In file included from /home/emaisin/src/binutils-gdb/gdb/common/gdb_unique_ptr.h:23:
      In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/memory:81:
      /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/bits/unique_ptr.h:76:2: error: delete called on non-final 'mapped_debug_names' that has virtual functions but non-virtual destructor [-Werror,-Wdelete-non-virtual-dtor]
              delete __ptr;
      /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/bits/unique_ptr.h:236:4: note: in instantiation of member function 'std::default_delete<mapped_debug_names>::operator()' requested here
      /home/emaisin/src/binutils-gdb/gdb/dwarf2read.c:2374:21: note: in instantiation of member function 'std::unique_ptr<mapped_debug_names, std::default_delete<mapped_debug_names> >::~unique_ptr' requested here
      dwarf2_per_objfile::dwarf2_per_objfile (struct objfile *objfile_,
      This patch silences these warnings by making the classes final.
      	* dwarf2read.c (struct mapped_debug_names): Make final.
      	(struct mapped_index): Make final.