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

  1. 15 Feb, 2017 1 commit
  2. 14 Feb, 2017 1 commit
  3. 13 Feb, 2017 1 commit
  4. 12 Feb, 2017 1 commit
  5. 11 Feb, 2017 1 commit
  6. 10 Feb, 2017 1 commit
  7. 09 Feb, 2017 1 commit
  8. 08 Feb, 2017 1 commit
  9. 07 Feb, 2017 1 commit
  10. 06 Feb, 2017 1 commit
  11. 05 Feb, 2017 1 commit
  12. 04 Feb, 2017 1 commit
  13. 03 Feb, 2017 1 commit
  14. 02 Feb, 2017 1 commit
  15. 01 Feb, 2017 1 commit
  16. 31 Jan, 2017 1 commit
  17. 30 Jan, 2017 1 commit
  18. 29 Jan, 2017 1 commit
  19. 28 Jan, 2017 1 commit
  20. 27 Jan, 2017 1 commit
  21. 26 Jan, 2017 1 commit
  22. 25 Jan, 2017 1 commit
  23. 24 Jan, 2017 1 commit
  24. 23 Jan, 2017 1 commit
  25. 22 Jan, 2017 1 commit
  26. 21 Jan, 2017 5 commits
    • Joel Brobecker's avatar
      Bump GDB version number to 7.12.1.DATE-git. · 5d3cbab1
      Joel Brobecker authored
      gdb/ChangeLog:
      
      	* version.in: Set GDB version number to 7.12.1.DATE-git.
      	* PROBLEMS: Likewise.
      5d3cbab1
    • Joel Brobecker's avatar
      Document the GDB 7.12.1 release in gdb/ChangeLog · 65bd0bb6
      Joel Brobecker authored
      gdb/ChangeLog:
      
      	GDB 7.12.1 released.
      65bd0bb6
    • Joel Brobecker's avatar
      Set GDB version number to 7.12.1. · 59b10245
      Joel Brobecker authored
      gdb/ChangeLog:
      
      	* version.in: Set GDB version number to 7.12.1.
      	* PROBLEMS: Likewise.
      59b10245
    • Simon Marchi's avatar
      Fix python-interactive with Python 3.6 · 3fc6097b
      Simon Marchi authored
      New in v2:
      
       - Define PyMem_RawMalloc as PyMem_Malloc for Python < 3.4 and use
         PyMem_RawMalloc in the code.
      
      Since Python 3.4, the callback installed in PyOS_ReadlineFunctionPointer
      should return a value allocated with PyMem_RawMalloc instead of
      PyMem_Malloc.  The reason is that PyMem_Malloc must be called with the
      Python Global Interpreter Lock (GIL) held, which is not the case in the
      context where this function is called.  PyMem_RawMalloc was introduced
      for cases like this.
      
      In Python 3.6, it looks like they added an assert to verify that
      PyMem_Malloc was not called without the GIL.  The consequence is that
      typing anything in the python-interactive mode of gdb crashes the
      process.  The same behavior was observed with the official package on
      Arch Linux as well as with a manual Python build on Ubuntu 14.04.
      
      This is what is shown with a debug build of Python 3.6 (the error with a
      non-debug build is far less clear):
      
        (gdb) pi
        >>> print(1)
        Fatal Python error: Python memory allocator called without holding the GIL
      
        Current thread 0x00007f1459af8780 (most recent call first):
        [1]    21326 abort      ./gdb
      
      and the backtrace:
      
        #0  0x00007ffff618bc37 in raise () from /lib/x86_64-linux-gnu/libc.so.6
        #1  0x00007ffff618f028 in abort () from /lib/x86_64-linux-gnu/libc.so.6
        #2  0x00007ffff6b104d6 in Py_FatalError (msg=msg@entry=0x7ffff6ba15b8 "Python memory allocator called without holding the GIL") at Python/pylifecycle.c:1457
        #3  0x00007ffff6a37a68 in _PyMem_DebugCheckGIL () at Objects/obmalloc.c:1972
        #4  0x00007ffff6a3804e in _PyMem_DebugFree (ctx=0x7ffff6e65290 <_PyMem_Debug+48>, ptr=0x24f8830) at Objects/obmalloc.c:1994
        #5  0x00007ffff6a38e1d in PyMem_Free (ptr=<optimized out>) at Objects/obmalloc.c:442
        #6  0x00007ffff6b866c6 in _PyFaulthandler_Fini () at ./Modules/faulthandler.c:1369
        #7  0x00007ffff6b104bd in Py_FatalError (msg=msg@entry=0x7ffff6ba15b8 "Python memory allocator called without holding the GIL") at Python/pylifecycle.c:1431
        #8  0x00007ffff6a37a68 in _PyMem_DebugCheckGIL () at Objects/obmalloc.c:1972
        #9  0x00007ffff6a37aa3 in _PyMem_DebugMalloc (ctx=0x7ffff6e65290 <_PyMem_Debug+48>, nbytes=5) at Objects/obmalloc.c:1980
        #10 0x00007ffff6a38d91 in PyMem_Malloc (size=<optimized out>) at Objects/obmalloc.c:418
        #11 0x000000000064dbe2 in gdbpy_readline_wrapper (sys_stdin=0x7ffff6514640 <_IO_2_1_stdin_>, sys_stdout=0x7ffff6514400 <_IO_2_1_stdout_>, prompt=0x7ffff4d4f7d0 ">>> ")
          at /home/emaisin/src/binutils-gdb/gdb/python/py-gdb-readline.c:75
      
      The documentation is very clear about it [1] and it was also mentioned
      in the "What's New In Python 3.4" page [2].
      
      [1] https://docs.python.org/3/c-api/veryhigh.html#c.PyOS_ReadlineFunctionPointer
      [2] https://docs.python.org/3/whatsnew/3.4.html#changes-in-the-c-api
      
      gdb/ChangeLog:
      
      	* python/python-internal.h (PyMem_RawMalloc): Define for
      	Python < 3.4.
      	* python/py-gdb-readline.c (gdbpy_readline_wrapper): Use
      	PyMem_RawMalloc instead of PyMem_Malloc.
      3fc6097b
    • GDB Administrator's avatar
      Automatic date update in version.in · 79209b79
      GDB Administrator authored
      79209b79
  27. 20 Jan, 2017 2 commits
    • Yao Qi's avatar
      Throw SJ/LJ exception on error in disassembly · e2285602
      Yao Qi authored
      PR 20939 reports that GDB will abort on memory error in disassembly,
      
      (gdb) disassemble 0x0,+4
      Dump of assembler code from 0x0 to 0x4:
      terminate called after throwing an instance of 'gdb_exception_RETURN_MASK_ERROR'
         0x0000000000000000:	Aborted
      
      (gdb) guile (print (arch-disassemble arch 0 #:size 4))^M
      terminate called after throwing an instance of 'gdb_exception_RETURN_MASK_ERROR'^M
      ERROR: Process no longer exists
      
      This patch fixes PR 20939 by catching C++ exception, throwing SJ/LJ
      exception in the call back passed to C functions of opcodes, and
      catching SJ/LJ exception in gdb, and throw exception.
      
      The patch follows this commit
      
       89525768
       Propagate GDB/C++ exceptions across readline using sj/lj-based TRY/CATCH
      
      rather than "backport" the fix to this PR I posted for mainline
      https://sourceware.org/ml/gdb-patches/2017-01/msg00288.html because the
      fix for mainline includes 1) some changes to opcodes, 2) some refactors
      in C++.  All of them are risky to backport to 7.12 branch.
      
      With this patch applied to 7.12 branch, GDB doesn't abort on memory error
      in disassembly.  It fixes some test failures in gdb.guile/scm-disasm.exp
      and gdb.python/py-arch.exp on aarch64-linux.
      
      -ERROR: Process no longer exists
      -UNRESOLVED: gdb.guile/scm-disasm.exp: test bad memory access
      +PASS: gdb.guile/scm-disasm.exp: test bad memory access
      
      -ERROR: Process no longer exists
      -UNRESOLVED: gdb.python/py-arch.exp: test bad memory access
      +PASS: gdb.python/py-arch.exp: test bad memory access
      
      I'll add the scm-disasm test to master later.
      
      gdb:
      
      2017-01-20  Yao Qi  <yao.qi@linaro.org>
      
      	PR gdb/20939
      	* disasm.c (dis_asm_memory_error): Catch the error and rethrow
      	it as a SJ/LJ exception.  Add GDB_NOEXCEPT.
      	(disasm_print_insn_noexcept): New function.
      	(disasm_print_insn): New function.
      	(gdb_pretty_print_insn): Call disasm_print_insn instead of
      	gdbarch_print_insn.
      	(gdb_print_insn): Likewise.
      	(gdb_buffered_insn_length): Likewise.
      	* event-top.c (GDB_NOEXCEPT): Move it to ...
      	* exceptions.h (GDB_NOEXCEPT): ... here.
      	* guile/scm-disasm.c (gdbscm_disasm_memory_error): Remove.
      	(gdbscm_print_insn_from_port): Don't set di.memory_errro_func.
      	Call disasm_print_insn rather than gdbarch_print_insn.
      e2285602
    • GDB Administrator's avatar
      Automatic date update in version.in · c3766ac6
      GDB Administrator authored
      c3766ac6
  28. 19 Jan, 2017 1 commit
  29. 18 Jan, 2017 1 commit
  30. 17 Jan, 2017 1 commit
  31. 16 Jan, 2017 1 commit
  32. 15 Jan, 2017 1 commit
  33. 14 Jan, 2017 1 commit
  34. 13 Jan, 2017 1 commit
  35. 12 Jan, 2017 1 commit
    • Tom Tromey's avatar
      Fix some error-handling bugs in python frame filters · df1fe27b
      Tom Tromey authored
      While writing a Python frame filter, I found a few bugs in the current
      frame filter code.  In particular:
      
      * One spot converts a Python long to a CORE_ADDR using PyLong_AsLong.
        However, this can fail on overflow.  I changed this to use
        get_addr_from_python.
      
      * Another spot is doing the same but with PyLong_AsUnsignedLongLong; I
        changed this as well just for consistency.
      
      * Converting line numbers can print "-1" if conversion from long
        fails.  This isn't fatal but just a bit ugly.
      
      I've included a test case for the first issue.  The line number one
      didn't seem important enough to bother with.
      
      2016-11-08  Tom Tromey  <tom@tromey.com>
      
      	* python/py-framefilter.c (py_print_frame): Use
      	get_addr_from_python.  Check for errors when getting line number.
      
      2016-11-08  Tom Tromey  <tom@tromey.com>
      
      	* gdb.python/py-framefilter.py (ElidingFrameDecorator.address):
      	New method.
      df1fe27b