and though bugs are the bane of my existence, rest assured the wretched thing will get the best of care here

  1. 20 Sep, 2019 2 commits
  2. 19 Sep, 2019 3 commits
    • Tom Tromey's avatar
      Add Rust support to source highlighting · 60cdff2f
      Tom Tromey authored
      [ Backport of master commit d806ea2d. ]
      
      Currently, no release of GNU Source Highlight supports Rust.  However,
      I've checked in a patch to do so there, and I plan to make a new
      release sometime this summer.
      
      This patch prepares gdb for that by adding support for Rust to the
      source highlighting code.
      
      Because Source Highlight will throw an exception if the language is
      unrecognized, this also changes gdb to ignore exceptions here.  This
      will cause gdb to fall back to un-highlighted source text.
      
      This updates gdb's configure script to reject the combination of
      Source Highlight and -static-libstdc++.  This is done because it's not
      possible to use -static-libstdc++ and then catch exceptions from a
      shared library.
      
      Tested with the current and development versions of Source Highlight.
      
      gdb/ChangeLog
      2019-08-19  Tom Tromey  <tom@tromey.com>
      
      	PR gdb/25009
      	* configure: Rebuild.
      	* configure.ac: Disallow the combination of -static-libstdc++ and
      	source highlight.
      	* source-cache.c (get_language_name): Handle rust.
      	(source_cache::get_source_lines): Ignore highlighting exceptions.
      60cdff2f
    • Tom Tromey's avatar
      Add --with-static-standard-libraries to the top level · ef93dd73
      Tom Tromey authored
      [ Backport of master commit c1a5d03a. ]
      
      gdb should normally not be linked with -static-libstdc++.  Currently
      this has not caused problems, but it's incompatible with catching an
      exception thrown from a shared library -- and a subsequent patch
      changes gdb to do just this.
      
      This patch adds a new --with-static-standard-libraries flag to the
      top-level configure.  It defaults to "auto", which means enabled if
      gcc is being built, and disabled otherwise.
      
      ChangeLog
      2019-08-19  Tom Tromey  <tom@tromey.com>
      
      	PR gdb/25009
      	* configure: Rebuild.
      	* configure.ac: Add --with-static-standard-libraries.
      ef93dd73
    • GDB Administrator's avatar
      Automatic date update in version.in · fe3e3465
      GDB Administrator authored
      fe3e3465
  3. 18 Sep, 2019 5 commits
  4. 17 Sep, 2019 3 commits
    • Tom de Vries's avatar
      [gdb/testsuite] Fix regexp in skip_opencl_tests · fafa92ec
      Tom de Vries authored
      [ Backport of master commit d2b584a5. ]
      
      When running gdb-caching-proc.exp, if skip_opencl_tests fails like this:
      ...
      (gdb) run
      Starting program: \
        build/gdb/testsuite/outputs/gdb.base/gdb-caching-proc/opencltest13530.x
      CHK_ERR (clGetPlatformIDs (1, &platform, NULL), -1001)
      src/gdb/testsuite/lib/opencl_hostapp.c:73 error: Unknown
      [Inferior 1 (process 13600) exited with code 01]
      (gdb)
      skip_opencl_tests: OpenCL support not detected
      ...
      then this regexp in skip_opencl_tests fails to match:
      ...
              -re ".*$inferior_exited_re code.*${gdb_prompt} $" {
      ...
      so instead we hit the default clause after a 30 seconds timeout.  With the
      iteration count set at 10, we end up taking 6 minutes to run this test-case.
      
      Fix this by adding the missing "with" in the regexp, bring back the runtime to
      half a minute.
      
      Tested on x86_64-linux.
      
      gdb/testsuite/ChangeLog:
      
      2019-04-29  Tom de Vries  <tdevries@suse.de>
      
      	PR testsuite/25005
      	* lib/opencl.exp (skip_opencl_tests): Add missing "with" in regexp.
      fafa92ec
    • Sergio Durigan Junior's avatar
      Update ChangeLog entry of commit e9224f6d and... · 6f4f8f47
      Sergio Durigan Junior authored
      Update ChangeLog entry of commit e9224f6d and mention PR breakpoints/24541
      6f4f8f47
    • GDB Administrator's avatar
      Automatic date update in version.in · 74da8643
      GDB Administrator authored
      74da8643
  5. 16 Sep, 2019 1 commit
  6. 15 Sep, 2019 1 commit
  7. 14 Sep, 2019 1 commit
  8. 13 Sep, 2019 1 commit
  9. 12 Sep, 2019 1 commit
  10. 11 Sep, 2019 3 commits
    • Sergio Durigan Junior's avatar
      Adjust i386 registers on SystemTap probes' arguments (PR breakpoints/24541) · 3b0e664e
      Sergio Durigan Junior authored
      [ Backport of master commit 7d7571f0. ]
      
      This bug has been reported on PR breakpoints/24541, but it is possible
      to reproduce it easily by running:
      
        make check-gdb TESTS=gdb.base/stap-probe.exp RUNTESTFLAGS='--target_board unix/-m32'
      
      The underlying cause is kind of complex, and involves decisions made
      by GCC and the sys/sdt.h header file about how to represent a probe
      argument that lives in a register in 32-bit programs.  I'll use
      Andrew's example on the bug to illustrate the problem.
      
      libstdc++ has a probe named "throw" with two arguments.  On i386, the
      probe is:
      
        stapsdt              0x00000028       NT_STAPSDT (SystemTap probe descriptors)
          Provider: libstdcxx
          Name: throw
          Location: 0x00072c96, Base: 0x00133d64, Semaphore: 0x00000000
          Arguments: 4@%si 4@%di
      
      I.e., the first argument is an unsigned 32-bit value (represented by
      the "4@") that lives on %si, and the second argument is an unsigned
      32-bit value that lives on %di.  Note the discrepancy between the
      argument size reported by the probe (32-bit) and the register size
      being used to store the value (16-bit).
      
      However, if you take a look at the disassemble of a program that uses
      this probe, you will see:
      
          00072c80 <__cxa_throw@@CXXABI_1.3>:
             72c80:       57                      push   %edi
             72c81:       56                      push   %esi
             72c82:       53                      push   %ebx
             72c83:       8b 74 24 10             mov    0x10(%esp),%esi
             72c87:       e8 74 bf ff ff          call   6ec00 <__cxa_finalize@plt+0x980>
             72c8c:       81 c3 74 e3 10 00       add    $0x10e374,%ebx
             72c92:       8b 7c 24 14             mov    0x14(%esp),%edi
             72c96:       90                      nop                      <----------------- PROBE IS HERE
             72c97:       e8 d4 a2 ff ff          call   6cf70 <__cxa_get_globals@plt>
             72c9c:       83 40 04 01             addl   $0x1,0x4(%eax)
             72ca0:       83 ec 04                sub    $0x4,%esp
             72ca3:       ff 74 24 1c             pushl  0x1c(%esp)
             72ca7:       57                      push   %edi
             72ca8:       56                      push   %esi
             72ca9:       e8 62 a3 ff ff          call   6d010 <__cxa_init_primary_exception@plt>
             72cae:       8d 70 40                lea    0x40(%eax),%esi
             72cb1:       c7 00 01 00 00 00       movl   $0x1,(%eax)
             72cb7:       89 34 24                mov    %esi,(%esp)
             72cba:       e8 61 96 ff ff          call   6c320 <_Unwind_RaiseException@plt>
             72cbf:       89 34 24                mov    %esi,(%esp)
             72cc2:       e8 c9 84 ff ff          call   6b190 <__cxa_begin_catch@plt>
             72cc7:       e8 d4 b3 ff ff          call   6e0a0 <_ZSt9terminatev@plt>
             72ccc:       66 90                   xchg   %ax,%ax
             72cce:       66 90                   xchg   %ax,%ax
      
      Note how the program is actually using %edi, and not %di, to store the
      second argument.  This is the problem here.
      
      GDB will basically read the probe argument, then read the contents of
      %di, and then cast this value to uint32_t, which causes the wrong
      value to be obtained.  In the gdb.base/stap-probe.exp case, this makes
      GDB read the wrong memory location, and not be able to display a test
      string.  In Andrew's example, this causes GDB to actually stop at a
      "catch throw" when it should actually have *not* stopped.
      
      After some discussion with Frank Eigler and Jakub Jelinek, it was
      decided that this bug should be fixed on the client side (i.e., the
      program that actually reads the probes), and this is why I'm proposing
      this patch.
      
      The idea is simple: we will have a gdbarch method, which, for now, is
      only used by i386.  The generic code that deals with register operands
      on gdb/stap-probe.c will call this method if it exists, passing the
      current parse information, the register name and its number.
      
      The i386 method will then verify if the register size is greater or
      equal than the size reported by the stap probe (the "4@" part).  If it
      is, we're fine.  Otherwise, it will check if we're dealing with any of
      the "extendable" registers (like ax, bx, si, di, sp, etc.).  If we
      are, it will change the register name to include the "e" prefix.
      
      I have tested the patch here in many scenarios, and it fixes Andrew's
      bug and also the regressions I mentioned before, on
      gdb.base/stap-probe.exp.  No regressions where found on other tests.
      
      Comments?
      
      gdb/ChangeLog:
      2019-06-27  Sergio Durigan Junior  <sergiodj@redhat.com>
      
      	PR breakpoints/24541
      	* gdbarch.c: Regenerate.
      	* gdbarch.h: Regenerate.
      	* gdbarch.sh: Add 'stap_adjust_register'.
      	* i386-tdep.c: Include '<unordered_set>'.
      	(i386_stap_adjust_register): New function.
      	(i386_elf_init_abi): Register 'i386_stap_adjust_register'.
      	* stap-probe.c (stap_parse_register_operand): Call
      	'gdbarch_stap_adjust_register'.
      3b0e664e
    • Sergio Durigan Junior's avatar
      Make stap-probe.c:stap_parse_register_operand's "regname" an std::string · e9224f6d
      Sergio Durigan Junior authored
      [ Backport of master commit 677052f2. ]
      
      This patch simplifies the code of
      stap-probe.c:stap_parse_register_operand by making "regname" an
      std::string.  No functionality change.
      
      I'm this code's maintainer, so I'm pushing this as it's a fairly
      trivial patch.
      
      gdb/ChangeLog:
      2019-05-16  Sergio Durigan Junior  <sergiodj@redhat.com>
      
      	* stap-probe.c (stap_parse_register_operand): Make "regname" an
      	"std::string", simplifying the algorithm.
      e9224f6d
    • GDB Administrator's avatar
      Automatic date update in version.in · d98f1d62
      GDB Administrator authored
      d98f1d62
  11. 10 Sep, 2019 1 commit
  12. 09 Sep, 2019 1 commit
  13. 08 Sep, 2019 1 commit
  14. 07 Sep, 2019 1 commit
  15. 06 Sep, 2019 1 commit
  16. 05 Sep, 2019 1 commit
  17. 04 Sep, 2019 1 commit
  18. 03 Sep, 2019 1 commit
  19. 02 Sep, 2019 1 commit
  20. 01 Sep, 2019 1 commit
  21. 31 Aug, 2019 1 commit
  22. 30 Aug, 2019 1 commit
  23. 29 Aug, 2019 1 commit
  24. 28 Aug, 2019 1 commit
  25. 27 Aug, 2019 1 commit
  26. 26 Aug, 2019 1 commit
  27. 25 Aug, 2019 1 commit
  28. 24 Aug, 2019 1 commit
  29. 23 Aug, 2019 1 commit