- 21 Jan, 2017 3 commits
-
-
Joel Brobecker authored
gdb/ChangeLog: * version.in: Set GDB version number to 7.12.1. * PROBLEMS: Likewise.
-
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. -
GDB Administrator authored
-
- 20 Jan, 2017 2 commits
-
-
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.
-
GDB Administrator authored
-
- 19 Jan, 2017 1 commit
-
-
GDB Administrator authored
-
- 18 Jan, 2017 1 commit
-
-
GDB Administrator authored
-
- 17 Jan, 2017 1 commit
-
-
GDB Administrator authored
-
- 16 Jan, 2017 1 commit
-
-
GDB Administrator authored
-
- 15 Jan, 2017 1 commit
-
-
GDB Administrator authored
-
- 14 Jan, 2017 1 commit
-
-
GDB Administrator authored
-
- 13 Jan, 2017 1 commit
-
-
GDB Administrator authored
-
- 12 Jan, 2017 2 commits
-
-
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.
-
GDB Administrator authored
-
- 11 Jan, 2017 1 commit
-
-
GDB Administrator authored
-
- 10 Jan, 2017 1 commit
-
-
GDB Administrator authored
-
- 09 Jan, 2017 1 commit
-
-
GDB Administrator authored
-
- 08 Jan, 2017 1 commit
-
-
GDB Administrator authored
-
- 07 Jan, 2017 1 commit
-
-
GDB Administrator authored
-
- 06 Jan, 2017 1 commit
-
-
GDB Administrator authored
-
- 05 Jan, 2017 1 commit
-
-
GDB Administrator authored
-
- 04 Jan, 2017 1 commit
-
-
GDB Administrator authored
-
- 03 Jan, 2017 1 commit
-
-
GDB Administrator authored
-
- 02 Jan, 2017 1 commit
-
-
GDB Administrator authored
-
- 01 Jan, 2017 2 commits
-
-
Joel Brobecker authored
This applies the second part of GDB's End of Year Procedure, which updates the copyright year range in all of GDB's files (the first part is ommitted on this branch). gdb/ChangeLog: Update copyright year range in all GDB files. -
GDB Administrator authored
-
- 31 Dec, 2016 1 commit
-
-
GDB Administrator authored
-
- 30 Dec, 2016 1 commit
-
-
GDB Administrator authored
-
- 29 Dec, 2016 1 commit
-
-
GDB Administrator authored
-
- 28 Dec, 2016 1 commit
-
-
GDB Administrator authored
-
- 27 Dec, 2016 1 commit
-
-
GDB Administrator authored
-
- 26 Dec, 2016 1 commit
-
-
GDB Administrator authored
-
- 25 Dec, 2016 1 commit
-
-
GDB Administrator authored
-
- 24 Dec, 2016 1 commit
-
-
GDB Administrator authored
-
- 23 Dec, 2016 1 commit
-
-
GDB Administrator authored
-
- 22 Dec, 2016 1 commit
-
-
GDB Administrator authored
-
- 21 Dec, 2016 1 commit
-
-
GDB Administrator authored
-
- 20 Dec, 2016 3 commits
-
-
Pedro Alves authored
The readline/sjlj-exceptions fix added an unconditional use of noexcept, but that's only valid C++11, and 7.12 must build with C and C++03 too. Fix this by adding a GDB_EXCEPT macro that compiles away to nothing in C, and to throw() in C++03, which I've confirmed fixes the original issue just the same as noexcept, with GCC 7 + -std=gnu+03 + sjlj-exceptions. gdb/ChangeLog: 2016-12-20 Pedro Alves <palves@redhat.com> PR gdb/20977 * event-top.c (GDB_NOEXCEPT): Define. (gdb_rl_callback_read_char_wrapper_noexcept): Use GDB_NOEXCEPT instead of noexcept and use (void) instead of (). (gdb_rl_callback_handler): Use GDB_NOEXCEPT instead of noexcept.
-
Pedro Alves authored
Nowadays, GDB propagates C++ exceptions across readline using setjmp/longjmp 89525768 ("Propagate GDB/C++ exceptions across readline using sj/lj-based TRY/CATCH") because DWARF-based unwinding can't cross C functions compiled without -fexceptions (see details from the commit above). Unfortunately, toolchains that use SjLj-based C++ exceptions got broken with that fix, because _Unwind_SjLj_Unregister, which is put at the exit of a function, is not executed due to the longjmp added by that commit. (gdb) [New Thread 2936.0xb80] kill Thread 1 received signal SIGSEGV, Segmentation fault. 0x03ff662b in ?? () top?bt 15 #0 0x03ff662b in ?? () #1 0x00526b92 in stdin_event_handler (error=0, client_data=0x172ed8) at ../../binutils-gdb/gdb/event-top.c:555 #2 0x00525a94 in handle_file_event (ready_mask=<optimized out>, file_ptr=0x3ff5cb8) at ../../binutils-gdb/gdb/event-loop.c:733 #3 gdb_wait_for_event (block=block@entry=1) at ../../binutils-gdb/gdb/event-loop.c:884 #4 0x00525bfb in gdb_do_one_event () at ../../binutils-gdb/gdb/event-loop.c:347 #5 0x00525ce5 in start_event_loop () at ../../binutils-gdb/gdb/event-loop.c:371 #6 0x0051fada in captured_command_loop (data=0x0) at ../../binutils-gdb/gdb/main.c:324 #7 0x0051cf5d in catch_errors ( func=func@entry=0x51fab0 <captured_command_loop(void*)>, func_args=func_args@entry=0x0, errstring=errstring@entry=0x7922bf <VEC_interp_factory_p_quick_push(VEC_inte rp_factory_p*, interp_factory*, char const*, unsigned int)::__PRETTY_FUNCTION__+351> "", mask=mask@entry=RETURN_MASK_ALL) at ../../binutils-gdb/gdb/exceptions.c:236 #8 0x00520f0c in captured_main (data=0x328feb4) at ../../binutils-gdb/gdb/main.c:1149 #9 gdb_main (args=args@entry=0x328feb4) at ../../binutils-gdb/gdb/main.c:1159 #10 0x0071e400 in main (argc=1, argv=0x171220) at ../../binutils-gdb/gdb/gdb.c:32 Fix this by making the functions involved in setjmp/longjmp as noexcept, so that the compiler knows it doesn't need to emit the _Unwind_SjLj_Register / _Unwind_SjLj_Unregister calls for C++ exceptions. Tested on x86_64 Fedora 23 with: - GCC 5.3.1 w/ DWARF-based exceptions. - GCC 7 built with --enable-sjlj-exceptions. gdb/ChangeLog: 2016-12-20 Pedro Alves <palves@redhat.com> Yao Qi <yao.qi@linaro.org> PR gdb/20977 * event-top.c (gdb_rl_callback_read_char_wrapper_noexcept): New noexcept function, factored out from ... (gdb_rl_callback_read_char_wrapper): ... this. (gdb_rl_callback_handler): Mark noexcept.
-
GDB Administrator authored
-