1. 23 Dec, 2018 2 commits
  2. 22 Dec, 2018 1 commit
  3. 21 Dec, 2018 2 commits
    • Paul Marechal's avatar
      gdb: Fix "info os <unknown>" command · 6ef08cc9
      Paul Marechal authored
      Running `info os someUnknownOsType` is crashing when gdb is built with
      -D_GLIBCXX_DEBUG:
      
      	/usr/include/c++/5/debug/vector:439:error: attempt to
      	access an element in an empty container.
      
      In target_read_stralloc from target.c, the call to
      target_read_alloc_1 can return an empty vector, we then call vector::back on
      this vector, which is invalid.
      
      This commit adds a check for emptiness before trying to call
      vector::back on it. It also adds test to check for `info os <unknown>`
      to return the proper error message.
      
      This is a regression in gdb 8.2 and this patch restores the behavior of
      previous versions.
      
      gdb/ChangeLog:
      
      	PR gdb/23974
      	* target.c (target_read_stralloc): Check for empty vector.
      
      gdb/testsuite/ChangeLog:
      
      	PR gdb/23974
      	* gdb.base/info-os.exp: Check return for unknown "info os" type.
      6ef08cc9
    • GDB Administrator's avatar
      Automatic date update in version.in · 9a67ecf9
      GDB Administrator authored
      9a67ecf9
  4. 20 Dec, 2018 1 commit
  5. 19 Dec, 2018 2 commits
  6. 18 Dec, 2018 2 commits
    • Sergio Durigan Junior's avatar
      Fix dwarf2read.c:dwarf2_find_containing_comp_unit's binary search · 438b265f
      Sergio Durigan Junior authored
      First of all, I would like to express my gratitude to Keith Seitz, Jan
      Kratochvil and Tom Tromey, who were really kind and helped a lot with
      this bug.  The patch itself was authored by Jan.
      
      This all began with:
      
        https://bugzilla.redhat.com/show_bug.cgi?id=1639242
        py-bt is broken, results in exception
      
      In summary, the error reported by the bug above is:
      
        $ gdb -args python3
        GNU gdb (GDB) Fedora 8.1.1-3.fc28
        (...)
        Reading symbols from python3...Reading symbols from /usr/lib/debug/usr/bin/python3.6-3.6.6-1.fc28.x86_64.debug...done.
        done.
        Dwarf Error: could not find partial DIE containing offset 0x316 [in module /usr/lib/debug/usr/bin/python3.6-3.6.6-1.fc28.x86_64.debug]
      
      After a long investigation, and after thinking that the problem might
      actually be on DWZ's side, we were able to determine that there's
      something wrong going on when
      dwarf2read.c:dwarf2_find_containing_comp_unit performs a binary search
      over all of the CUs belonging to an objfile in order to find the CU
      which contains a DIE at an specific offset.  The current algorithm is:
      
        static struct dwarf2_per_cu_data *
        dwarf2_find_containing_comp_unit (sect_offset sect_off,
      				    unsigned int offset_in_dwz,
      				    struct dwarf2_per_objfile *dwarf2_per_objfile)
        {
          struct dwarf2_per_cu_data *this_cu;
          int low, high;
          const sect_offset *cu_off;
      
          low = 0;
          high = dwarf2_per_objfile->all_comp_units.size () - 1;
          while (high > low)
            {
      	struct dwarf2_per_cu_data *mid_cu;
      	int mid = low + (high - low) / 2;
      
      	mid_cu = dwarf2_per_objfile->all_comp_units[mid];
      	cu_off = &mid_cu->sect_off;
      	if (mid_cu->is_dwz > offset_in_dwz
      	    || (mid_cu->is_dwz == offset_in_dwz && *cu_off >= sect_off))
      	  high = mid;
      	else
      	  low = mid + 1;
            }
      
      For the sake of this example, let's consider that "sect_off =
      0x7d".
      
      There are a few important things going on here.  First,
      "dwarf2_per_objfile->all_comp_units ()" will be sorted first by
      whether the CU is a DWZ CU, and then by cu->sect_off.  In this
      specific bug, "offset_in_dwz" is false, which means that, for the most
      part of the loop, we're going to do "high = mid" (i.e, we'll work with
      the lower part of the vector).
      
      In our particular case, when we reach the part where "mid_cu->is_dwz
      == offset_in_dwz" (i.e, both are false), we end up with "high = 2" and
      "mid = 1".  I.e., there are only 2 elements in the vector who are not
      DWZ.  The vector looks like this:
      
        #0: cu->sect_off = 0;   length = 114;  is_dwz = false  <-- low
        #1: cu->sect_off = 114; length = 7796; is_dwz = false  <-- mid
        #2: cu->sect_off = 0;   length = 28;   is_dwz = true   <-- high
        ...
      
      The CU we want is #1, which is exactly where "mid" is.  Also, #1 is
      not DWZ, which is also exactly what we want.  So we perform the second
      comparison:
      
        (mid_cu->is_dwz == offset_in_dwz && *cu_off >= sect_off)
                                            ^^^^^^^^^^^^^^^^^^^
      
      Because "*cu_off = 114" and "sect_off = 0x7d", this evaluates to
      false, so we end up with "low = mid + 1 = 2", which actually gives us
      the wrong CU (i.e., a CU that is DWZ).  Next in the code, GDB does:
      
          gdb_assert (low == high);
          this_cu = dwarf2_per_objfile->all_comp_units[low];
          cu_off = &this_cu->sect_off;
          if (this_cu->is_dwz != offset_in_dwz || *cu_off > sect_off)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            {
      	if (low == 0 || this_cu->is_dwz != offset_in_dwz)
      	  error (_("Dwarf Error: could not find partial DIE containing "
      		 "offset %s [in module %s]"),
      		 sect_offset_str (sect_off),
      		 bfd_get_filename (dwarf2_per_objfile->objfile->obfd));
      	...
      
      Triggering the error we saw in the original bug report.
      
      It's important to notice that we see the error message because the
      selected CU is a DWZ one, but we're looking for a non-DWZ CU here.
      However, even when the selected CU is *not* a DWZ (and we don't see
      any error message), we still end up with the wrong CU.  For example,
      suppose that the vector had:
      
        #0: cu->sect_off = 0;    length = 114;  is_dwz = false
        #1: cu->sect_off = 114;  length = 7796; is_dwz = false
        #2: cu->sect_off = 7910; length = 28;   is_dwz = false
        ...
      
      I.e., #2's "is_dwz" is false instead of true.  In this case, we still
      want #1, because that's where the DIE is located.  After the loop ends
      up in #2, we have "is_dwz" as false, which is what we wanted, so we
      compare offsets.  In this case, "7910 >= 0x7d", so we set "mid = high
      = 2".  Next iteration, we have "mid = 0 + (2 - 0) / 2 = 1", and thus
      we examining #1.  "is_dwz" is still false, but "114 >= 0x7d" also
      evaluates to false, so "low = mid + 1 = 2", which makes the loop stop.
      Therefore, we end up choosing #2 as our CU, even though #1 is the
      right one.
      
      The problem here is happening because we're comparing "sect_off"
      directly against "*cu_off", while we should actually be comparing
      against "*cu_off + mid_cu->length" (i.e., the end offset):
      
        ...
        || (mid_cu->is_dwz == offset_in_dwz
            && *cu_off + mid_cu->length >= sect_off))
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        ...
      
      And this is what the patch does.  The idea is that if GDB is searching
      for an offset that falls above the *end* of the CU being
      analyzed (i.e., "mid"), then the next iteration should try a
      higher-offset CU next.  The previous algorithm was using
      the *beginning* of the CU.
      
      Unfortunately, I could not devise a testcase for this problem, so I am
      proposing a fix with this huge explanation attached to it in the hope
      that it is sufficient.  After talking a bit to Keith (our testcase
      guru), it seems that one would have to create an objfile with both DWZ
      and non-DWZ sections, which may prove very hard to do, I think.
      
      I ran this patch on our BuildBot, and no regressions were detected.
      
      gdb/ChangeLog:
      2018-11-30  Jan Kratochvil  <jan.kratochvil@redhat.com>
      	    Keith Seitz  <keiths@redhat.com>
      	    Tom Tromey  <tom@tromey.com>
      	    Sergio Durigan Junior  <sergiodj@redhat.com>
      
      	https://bugzilla.redhat.com/show_bug.cgi?id=1613614
      	PR gdb/24003
      	* dwarf2read.c (dwarf2_find_containing_comp_unit): Add
      	'mid_cu->length' to '*cu_off' when checking if 'sect_off' is
      	inside the CU.
      438b265f
    • GDB Administrator's avatar
      Automatic date update in version.in · 870368e0
      GDB Administrator authored
      870368e0
  7. 17 Dec, 2018 1 commit
  8. 16 Dec, 2018 1 commit
  9. 15 Dec, 2018 1 commit
  10. 14 Dec, 2018 1 commit
  11. 13 Dec, 2018 1 commit
  12. 12 Dec, 2018 1 commit
  13. 11 Dec, 2018 1 commit
  14. 10 Dec, 2018 1 commit
  15. 09 Dec, 2018 1 commit
  16. 08 Dec, 2018 1 commit
  17. 07 Dec, 2018 1 commit
  18. 06 Dec, 2018 1 commit
  19. 05 Dec, 2018 1 commit
  20. 04 Dec, 2018 1 commit
  21. 03 Dec, 2018 1 commit
  22. 02 Dec, 2018 1 commit
  23. 01 Dec, 2018 1 commit
  24. 30 Nov, 2018 1 commit
  25. 29 Nov, 2018 1 commit
  26. 28 Nov, 2018 1 commit
  27. 27 Nov, 2018 1 commit
  28. 26 Nov, 2018 1 commit
  29. 25 Nov, 2018 1 commit
  30. 24 Nov, 2018 1 commit
  31. 23 Nov, 2018 1 commit
  32. 22 Nov, 2018 1 commit
  33. 21 Nov, 2018 2 commits
    • Benno Fünfstück's avatar
      Make command-repeat work after gdb.execute · 7d9e5163
      Benno Fünfstück authored
      Since commit
      
        56bcdbea ("Let gdb.execute handle multi-line commands")
      
      command repetition after using the `gdb.execute` Python function
      fails (the previous command is not repeated anymore). This happens
      because read_command_lines_1 sets dont_repeat, but the call to
      prevent_dont_repeat in execute_gdb_command is later.
      
      The fix is to move the call to prevent_dont_repeat to the beginning of
      the function.
      
      Tested on my laptop (ArchLinux-x86_64).
      
      gdb/ChangeLog:
      
      	PR python/23714
      	* gdb/python/python.c (execute_gdb_command): Call
      	prevent_dont_repeat earlier to avoid affecting dont_repeat.
      
      gdb/testuite/ChangeLog:
      
      	PR python/23714
      	* gdb.python/python.exp: Test command repetition after
      	gdb.execute.
      7d9e5163
    • GDB Administrator's avatar
      Automatic date update in version.in · 646f353b
      GDB Administrator authored
      646f353b
  34. 20 Nov, 2018 1 commit
  35. 19 Nov, 2018 1 commit
    • Pedro Alves's avatar
      gdb.base/warning.exp tweaks · 52ec8c2b
      Pedro Alves authored
      #1- Check that the warning is emitted.
      
      #2- Avoid overriding INTERNAL_GDBFLAGS, as per documentated in
          gdb/testsuite/README:
      
       ~~~
       The testsuite does not override a value provided by the user.
       ~~~
      
      We don't actually need to tweak INTERNAL_GDBFLAGS, we just need to
      append out -data-directory to GDBFLAGS, because each passed
      -data-directory option leads to a call to the warning:
      
       $ ./gdb -data-directory=foo -data-directory=bar
       Warning: foo: No such file or directory.
       Warning: bar: No such file or directory.
       [...]
      
      2018-11-19  Pedro Alves  <palves@redhat.com>
      
      	* gdb.base/warning.exp: Don't override INTERNAL_FLAGS.  Use
      	gdb_spawn_with_cmdline_opts instead of gdb_start.  Check that we
      	see the expected warning.
      52ec8c2b