binutils-gdb/gdb/python/py-gdb-readline.c

114 lines
3.2 KiB
C
Raw Normal View History

/* Readline support for Python.
Copyright (C) 2012-2017 Free Software Foundation, Inc.
This file is part of GDB.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>. */
#include "defs.h"
#include "python-internal.h"
#include "top.h"
#include "cli/cli-utils.h"
Fix python-interactive with Python 3.6 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.
2017-01-21 02:39:08 +01:00
/* Readline function suitable for PyOS_ReadlineFunctionPointer, which
is used for Python's interactive parser and raw_input. In both
cases, sys_stdin and sys_stdout are always stdin and stdout
respectively, as far as I can tell; they are ignored and
command_line_input is used instead. */
static char *
gdbpy_readline_wrapper (FILE *sys_stdin, FILE *sys_stdout,
Fix build with Python 3.4 (PR python/16784) The type of the function pointer PyOS_ReadlineFunctionPointer (part of the Python C API), which we use, slightly changed starting with Python 3.4. The signature went from PyAPI_DATA(char) *(*PyOS_ReadlineFunctionPointer)(FILE *, FILE *, char *); to PyAPI_DATA(char) *(*PyOS_ReadlineFunctionPointer)(FILE *, FILE *, const char *); The parameter that changed is the prompt text. This commits adjust gdb accordingly by making the prompt_arg parameter const, as well as the fallouts of that. I needed to rework how annotations are added to the prompt, since the it is now const. If annotations are enabled, it will make a copy of the prompt overwrite the prompt variable that is used throughout the function. Otherwise, no copy is done and the original prompt_arg value is passed. I changed the signature of deprecated_readline_hook. I would've changed any user of it, but it seems like nothing is using it, Built-tested with python 2.7.x, 3.3.y and 3.4.z. gdb/ChangeLog: * defs.h (gdb_readline): Constify argument. (gdb_readline_wrapper): Same. (command_line_input): Same. (deprecated_readline_hook): Same. * top.c (deprecated_readline_hook): Same. (gdb_readline): Same. (gdb_readline_wrapper): Same. (command_line_input): Constify argument. Pass prompt to called functions instead of local_prompt, overwriting prompt if using annotations. * event-top.h (display_gdb_prompt): Constify argument. * event-top.c (display_gdb_prompt): Same. * python/py-gdb-readline.c (gdbpy_readline_wrapper): Constify argument if building with Python 3.4 and up. Signed-off-by: Simon Marchi <simon.marchi@ericsson.com>
2014-12-15 17:38:03 +01:00
#if PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 4
const char *prompt)
#else
char *prompt)
Fix build with Python 3.4 (PR python/16784) The type of the function pointer PyOS_ReadlineFunctionPointer (part of the Python C API), which we use, slightly changed starting with Python 3.4. The signature went from PyAPI_DATA(char) *(*PyOS_ReadlineFunctionPointer)(FILE *, FILE *, char *); to PyAPI_DATA(char) *(*PyOS_ReadlineFunctionPointer)(FILE *, FILE *, const char *); The parameter that changed is the prompt text. This commits adjust gdb accordingly by making the prompt_arg parameter const, as well as the fallouts of that. I needed to rework how annotations are added to the prompt, since the it is now const. If annotations are enabled, it will make a copy of the prompt overwrite the prompt variable that is used throughout the function. Otherwise, no copy is done and the original prompt_arg value is passed. I changed the signature of deprecated_readline_hook. I would've changed any user of it, but it seems like nothing is using it, Built-tested with python 2.7.x, 3.3.y and 3.4.z. gdb/ChangeLog: * defs.h (gdb_readline): Constify argument. (gdb_readline_wrapper): Same. (command_line_input): Same. (deprecated_readline_hook): Same. * top.c (deprecated_readline_hook): Same. (gdb_readline): Same. (gdb_readline_wrapper): Same. (command_line_input): Constify argument. Pass prompt to called functions instead of local_prompt, overwriting prompt if using annotations. * event-top.h (display_gdb_prompt): Constify argument. * event-top.c (display_gdb_prompt): Same. * python/py-gdb-readline.c (gdbpy_readline_wrapper): Constify argument if building with Python 3.4 and up. Signed-off-by: Simon Marchi <simon.marchi@ericsson.com>
2014-12-15 17:38:03 +01:00
#endif
{
int n;
2013-01-31 Aleksandar Ristovski <aristovski@qnx.com> * charset.c (intermediate_encoding): Remove unused i. * completer.c (signal_completer): Remove unused i. * continuations.c (discard_my_continuations_1): Remove unused continuation_ptr. * corelow.c (core_close): Remove unuseD name. (get_core_siginfo): Remove unused pid. * cp-namespace.c (cp_lookup_symbol_imports_or_template): Remove unused i, cps. * dwarf2loc.c (dwarf2_compile_expr_to_ax): Remove unused base_offset. (loclist_describe_location): Remove unused first. * event-top.c (command_line_handler): Remove unused got_eof. * exec.c (exec_close_1): Remove unused need_symtab_cleanup. (resize_section_table): Remove unused old_value. * gdb_bfd.c (gdb_bfd_map_section): Remove unused header. * gnu-v3-abi.c (compute_vtable_size): Remove unused addr. * i386-tdep.c (i386_process_record): Remove unused rex. * infcmd.c (get_return_value): Remove unused uiout. * jv-lang.c (type_from_class): Remove unused is_array. * jv-valprint.c (java_val_print): Remove unused i. * linux-nat.c (linux_nat_stop_lwp): Remove unused ptid. * linux-thread-db.c (thread_db_find_new_threads_2): Remove unuseD pid. * m2-typeprint.c (m2_print_type): Remove unused code. * macroexp.c (get_character_constant): Remove unused body_start. (macro_stringify): Remove unused result. * objc-lang.c (find_methods): Remove unused gdbarch. * objfiles.c (filter_overlapping_sections): Remove unused abfd1, abfd2. * regcache.c (regcache_cooked_read): Remove unused gdbarch. * stack.c (print_frame_args): Remove unused summary. * thread.c (thread_apply_command): Remove unused p. * valarith.c (value_x_unop): Remove unused mangle_ptr. * valops.c (search_struct_method): Remove unused skip. * valprint.c (generic_val_print): Remove unused byte_order. * varobj.c (varobj_update): Remove unused changed. * cli/cli-cmds.c (complete_command): Remove unused next_item. (alias_command): Remove unused c. * mi/mi-cmd-catch.c (mi_catch_load_unload): Remove unused c. * mi/mi-main.c (mi_cmd_data_write_register_values): Remove unused format. (mi_cmd_data_write_memory): Remove unused word_format. (mi_cmd_data_write_memory_bytes): Remove unused r. * python/py-gdb-readline.c (gdbpy_readline_wrapper): Remove unused p_start, p_end. * python/python.c (_initialize_python): Remove unused cmd_name, cmd. * tui/tui-disasm.c (tui_set_disassem_content): Remove unused line_width. Reference: http://sourceware.org/ml/gdb-patches/2013-01/msg00766.html
2013-01-31 19:37:39 +01:00
char *p = NULL, *q;
Split TRY_CATCH into TRY + CATCH This patch splits the TRY_CATCH macro into three, so that we go from this: ~~~ volatile gdb_exception ex; TRY_CATCH (ex, RETURN_MASK_ERROR) { } if (ex.reason < 0) { } ~~~ to this: ~~~ TRY { } CATCH (ex, RETURN_MASK_ERROR) { } END_CATCH ~~~ Thus, we'll be getting rid of the local volatile exception object, and declaring the caught exception in the catch block. This allows reimplementing TRY/CATCH in terms of C++ exceptions when building in C++ mode, while still allowing to build GDB in C mode (using setjmp/longjmp), as a transition step. TBC, after this patch, is it _not_ valid to have code between the TRY and the CATCH blocks, like: TRY { } // some code here. CATCH (ex, RETURN_MASK_ERROR) { } END_CATCH Just like it isn't valid to do that with C++'s native try/catch. By switching to creating the exception object inside the CATCH block scope, we can get rid of all the explicitly allocated volatile exception objects all over the tree, and map the CATCH block more directly to C++'s catch blocks. The majority of the TRY_CATCH -> TRY+CATCH+END_CATCH conversion was done with a script, rerun from scratch at every rebase, no manual editing involved. After the mechanical conversion, a few places needed manual intervention, to fix preexisting cases where we were using the exception object outside of the TRY_CATCH block, and cases where we were using "else" after a 'if (ex.reason) < 0)' [a CATCH after this patch]. The result was folded into this patch so that GDB still builds at each incremental step. END_CATCH is necessary for two reasons: First, because we name the exception object in the CATCH block, which requires creating a scope, which in turn must be closed somewhere. Declaring the exception variable in the initializer field of a for block, like: #define CATCH(EXCEPTION, mask) \ for (struct gdb_exception EXCEPTION; \ exceptions_state_mc_catch (&EXCEPTION, MASK); \ EXCEPTION = exception_none) would avoid needing END_CATCH, but alas, in C mode, we build with C90, which doesn't allow mixed declarations and code. Second, because when TRY/CATCH are wired to real C++ try/catch, as long as we need to handle cleanup chains, even if there's no CATCH block that wants to catch the exception, we need for stop at every frame in the unwind chain and run cleanups, then rethrow. That will be done in END_CATCH. After we require C++, we'll still need TRY/CATCH/END_CATCH until cleanups are completely phased out -- TRY/CATCH in C++ mode will save/restore the current cleanup chain, like in C mode, and END_CATCH catches otherwise uncaugh exceptions, runs cleanups and rethrows, so that C++ cleanups and exceptions can coexist. IMO, this still makes the TRY/CATCH code look a bit more like a newcomer would expect, so IMO worth it even if we weren't considering C++. gdb/ChangeLog. 2015-03-07 Pedro Alves <palves@redhat.com> * common/common-exceptions.c (struct catcher) <exception>: No longer a pointer to volatile exception. Now an exception value. <mask>: Delete field. (exceptions_state_mc_init): Remove all parameters. Adjust. (exceptions_state_mc): No longer pop the catcher here. (exceptions_state_mc_catch): New function. (throw_exception): Adjust. * common/common-exceptions.h (exceptions_state_mc_init): Remove all parameters. (exceptions_state_mc_catch): Declare. (TRY_CATCH): Rename to ... (TRY): ... this. Remove EXCEPTION and MASK parameters. (CATCH, END_CATCH): New. All callers adjusted. gdb/gdbserver/ChangeLog: 2015-03-07 Pedro Alves <palves@redhat.com> Adjust all callers of TRY_CATCH to use TRY/CATCH/END_CATCH instead.
2015-03-07 16:14:14 +01:00
TRY
{
p = command_line_input (prompt, 0, "python");
}
/* Handle errors by raising Python exceptions. */
Split TRY_CATCH into TRY + CATCH This patch splits the TRY_CATCH macro into three, so that we go from this: ~~~ volatile gdb_exception ex; TRY_CATCH (ex, RETURN_MASK_ERROR) { } if (ex.reason < 0) { } ~~~ to this: ~~~ TRY { } CATCH (ex, RETURN_MASK_ERROR) { } END_CATCH ~~~ Thus, we'll be getting rid of the local volatile exception object, and declaring the caught exception in the catch block. This allows reimplementing TRY/CATCH in terms of C++ exceptions when building in C++ mode, while still allowing to build GDB in C mode (using setjmp/longjmp), as a transition step. TBC, after this patch, is it _not_ valid to have code between the TRY and the CATCH blocks, like: TRY { } // some code here. CATCH (ex, RETURN_MASK_ERROR) { } END_CATCH Just like it isn't valid to do that with C++'s native try/catch. By switching to creating the exception object inside the CATCH block scope, we can get rid of all the explicitly allocated volatile exception objects all over the tree, and map the CATCH block more directly to C++'s catch blocks. The majority of the TRY_CATCH -> TRY+CATCH+END_CATCH conversion was done with a script, rerun from scratch at every rebase, no manual editing involved. After the mechanical conversion, a few places needed manual intervention, to fix preexisting cases where we were using the exception object outside of the TRY_CATCH block, and cases where we were using "else" after a 'if (ex.reason) < 0)' [a CATCH after this patch]. The result was folded into this patch so that GDB still builds at each incremental step. END_CATCH is necessary for two reasons: First, because we name the exception object in the CATCH block, which requires creating a scope, which in turn must be closed somewhere. Declaring the exception variable in the initializer field of a for block, like: #define CATCH(EXCEPTION, mask) \ for (struct gdb_exception EXCEPTION; \ exceptions_state_mc_catch (&EXCEPTION, MASK); \ EXCEPTION = exception_none) would avoid needing END_CATCH, but alas, in C mode, we build with C90, which doesn't allow mixed declarations and code. Second, because when TRY/CATCH are wired to real C++ try/catch, as long as we need to handle cleanup chains, even if there's no CATCH block that wants to catch the exception, we need for stop at every frame in the unwind chain and run cleanups, then rethrow. That will be done in END_CATCH. After we require C++, we'll still need TRY/CATCH/END_CATCH until cleanups are completely phased out -- TRY/CATCH in C++ mode will save/restore the current cleanup chain, like in C mode, and END_CATCH catches otherwise uncaugh exceptions, runs cleanups and rethrows, so that C++ cleanups and exceptions can coexist. IMO, this still makes the TRY/CATCH code look a bit more like a newcomer would expect, so IMO worth it even if we weren't considering C++. gdb/ChangeLog. 2015-03-07 Pedro Alves <palves@redhat.com> * common/common-exceptions.c (struct catcher) <exception>: No longer a pointer to volatile exception. Now an exception value. <mask>: Delete field. (exceptions_state_mc_init): Remove all parameters. Adjust. (exceptions_state_mc): No longer pop the catcher here. (exceptions_state_mc_catch): New function. (throw_exception): Adjust. * common/common-exceptions.h (exceptions_state_mc_init): Remove all parameters. (exceptions_state_mc_catch): Declare. (TRY_CATCH): Rename to ... (TRY): ... this. Remove EXCEPTION and MASK parameters. (CATCH, END_CATCH): New. All callers adjusted. gdb/gdbserver/ChangeLog: 2015-03-07 Pedro Alves <palves@redhat.com> Adjust all callers of TRY_CATCH to use TRY/CATCH/END_CATCH instead.
2015-03-07 16:14:14 +01:00
CATCH (except, RETURN_MASK_ALL)
{
Split TRY_CATCH into TRY + CATCH This patch splits the TRY_CATCH macro into three, so that we go from this: ~~~ volatile gdb_exception ex; TRY_CATCH (ex, RETURN_MASK_ERROR) { } if (ex.reason < 0) { } ~~~ to this: ~~~ TRY { } CATCH (ex, RETURN_MASK_ERROR) { } END_CATCH ~~~ Thus, we'll be getting rid of the local volatile exception object, and declaring the caught exception in the catch block. This allows reimplementing TRY/CATCH in terms of C++ exceptions when building in C++ mode, while still allowing to build GDB in C mode (using setjmp/longjmp), as a transition step. TBC, after this patch, is it _not_ valid to have code between the TRY and the CATCH blocks, like: TRY { } // some code here. CATCH (ex, RETURN_MASK_ERROR) { } END_CATCH Just like it isn't valid to do that with C++'s native try/catch. By switching to creating the exception object inside the CATCH block scope, we can get rid of all the explicitly allocated volatile exception objects all over the tree, and map the CATCH block more directly to C++'s catch blocks. The majority of the TRY_CATCH -> TRY+CATCH+END_CATCH conversion was done with a script, rerun from scratch at every rebase, no manual editing involved. After the mechanical conversion, a few places needed manual intervention, to fix preexisting cases where we were using the exception object outside of the TRY_CATCH block, and cases where we were using "else" after a 'if (ex.reason) < 0)' [a CATCH after this patch]. The result was folded into this patch so that GDB still builds at each incremental step. END_CATCH is necessary for two reasons: First, because we name the exception object in the CATCH block, which requires creating a scope, which in turn must be closed somewhere. Declaring the exception variable in the initializer field of a for block, like: #define CATCH(EXCEPTION, mask) \ for (struct gdb_exception EXCEPTION; \ exceptions_state_mc_catch (&EXCEPTION, MASK); \ EXCEPTION = exception_none) would avoid needing END_CATCH, but alas, in C mode, we build with C90, which doesn't allow mixed declarations and code. Second, because when TRY/CATCH are wired to real C++ try/catch, as long as we need to handle cleanup chains, even if there's no CATCH block that wants to catch the exception, we need for stop at every frame in the unwind chain and run cleanups, then rethrow. That will be done in END_CATCH. After we require C++, we'll still need TRY/CATCH/END_CATCH until cleanups are completely phased out -- TRY/CATCH in C++ mode will save/restore the current cleanup chain, like in C mode, and END_CATCH catches otherwise uncaugh exceptions, runs cleanups and rethrows, so that C++ cleanups and exceptions can coexist. IMO, this still makes the TRY/CATCH code look a bit more like a newcomer would expect, so IMO worth it even if we weren't considering C++. gdb/ChangeLog. 2015-03-07 Pedro Alves <palves@redhat.com> * common/common-exceptions.c (struct catcher) <exception>: No longer a pointer to volatile exception. Now an exception value. <mask>: Delete field. (exceptions_state_mc_init): Remove all parameters. Adjust. (exceptions_state_mc): No longer pop the catcher here. (exceptions_state_mc_catch): New function. (throw_exception): Adjust. * common/common-exceptions.h (exceptions_state_mc_init): Remove all parameters. (exceptions_state_mc_catch): Declare. (TRY_CATCH): Rename to ... (TRY): ... this. Remove EXCEPTION and MASK parameters. (CATCH, END_CATCH): New. All callers adjusted. gdb/gdbserver/ChangeLog: 2015-03-07 Pedro Alves <palves@redhat.com> Adjust all callers of TRY_CATCH to use TRY/CATCH/END_CATCH instead.
2015-03-07 16:14:14 +01:00
/* Detect user interrupt (Ctrl-C). */
if (except.reason == RETURN_QUIT)
return NULL;
/* The thread state is nulled during gdbpy_readline_wrapper,
with the original value saved in the following undocumented
variable (see Python's Parser/myreadline.c and
Modules/readline.c). */
PyEval_RestoreThread (_PyOS_ReadlineTState);
gdbpy_convert_exception (except);
PyEval_SaveThread ();
return NULL;
}
Split TRY_CATCH into TRY + CATCH This patch splits the TRY_CATCH macro into three, so that we go from this: ~~~ volatile gdb_exception ex; TRY_CATCH (ex, RETURN_MASK_ERROR) { } if (ex.reason < 0) { } ~~~ to this: ~~~ TRY { } CATCH (ex, RETURN_MASK_ERROR) { } END_CATCH ~~~ Thus, we'll be getting rid of the local volatile exception object, and declaring the caught exception in the catch block. This allows reimplementing TRY/CATCH in terms of C++ exceptions when building in C++ mode, while still allowing to build GDB in C mode (using setjmp/longjmp), as a transition step. TBC, after this patch, is it _not_ valid to have code between the TRY and the CATCH blocks, like: TRY { } // some code here. CATCH (ex, RETURN_MASK_ERROR) { } END_CATCH Just like it isn't valid to do that with C++'s native try/catch. By switching to creating the exception object inside the CATCH block scope, we can get rid of all the explicitly allocated volatile exception objects all over the tree, and map the CATCH block more directly to C++'s catch blocks. The majority of the TRY_CATCH -> TRY+CATCH+END_CATCH conversion was done with a script, rerun from scratch at every rebase, no manual editing involved. After the mechanical conversion, a few places needed manual intervention, to fix preexisting cases where we were using the exception object outside of the TRY_CATCH block, and cases where we were using "else" after a 'if (ex.reason) < 0)' [a CATCH after this patch]. The result was folded into this patch so that GDB still builds at each incremental step. END_CATCH is necessary for two reasons: First, because we name the exception object in the CATCH block, which requires creating a scope, which in turn must be closed somewhere. Declaring the exception variable in the initializer field of a for block, like: #define CATCH(EXCEPTION, mask) \ for (struct gdb_exception EXCEPTION; \ exceptions_state_mc_catch (&EXCEPTION, MASK); \ EXCEPTION = exception_none) would avoid needing END_CATCH, but alas, in C mode, we build with C90, which doesn't allow mixed declarations and code. Second, because when TRY/CATCH are wired to real C++ try/catch, as long as we need to handle cleanup chains, even if there's no CATCH block that wants to catch the exception, we need for stop at every frame in the unwind chain and run cleanups, then rethrow. That will be done in END_CATCH. After we require C++, we'll still need TRY/CATCH/END_CATCH until cleanups are completely phased out -- TRY/CATCH in C++ mode will save/restore the current cleanup chain, like in C mode, and END_CATCH catches otherwise uncaugh exceptions, runs cleanups and rethrows, so that C++ cleanups and exceptions can coexist. IMO, this still makes the TRY/CATCH code look a bit more like a newcomer would expect, so IMO worth it even if we weren't considering C++. gdb/ChangeLog. 2015-03-07 Pedro Alves <palves@redhat.com> * common/common-exceptions.c (struct catcher) <exception>: No longer a pointer to volatile exception. Now an exception value. <mask>: Delete field. (exceptions_state_mc_init): Remove all parameters. Adjust. (exceptions_state_mc): No longer pop the catcher here. (exceptions_state_mc_catch): New function. (throw_exception): Adjust. * common/common-exceptions.h (exceptions_state_mc_init): Remove all parameters. (exceptions_state_mc_catch): Declare. (TRY_CATCH): Rename to ... (TRY): ... this. Remove EXCEPTION and MASK parameters. (CATCH, END_CATCH): New. All callers adjusted. gdb/gdbserver/ChangeLog: 2015-03-07 Pedro Alves <palves@redhat.com> Adjust all callers of TRY_CATCH to use TRY/CATCH/END_CATCH instead.
2015-03-07 16:14:14 +01:00
END_CATCH
/* Detect EOF (Ctrl-D). */
if (p == NULL)
{
Fix python-interactive with Python 3.6 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.
2017-01-21 02:39:08 +01:00
q = (char *) PyMem_RawMalloc (1);
if (q != NULL)
q[0] = '\0';
return q;
}
n = strlen (p);
/* Copy the line to Python and return. */
Fix python-interactive with Python 3.6 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.
2017-01-21 02:39:08 +01:00
q = (char *) PyMem_RawMalloc (n + 2);
if (q != NULL)
{
strcpy (q, p);
q[n] = '\n';
q[n + 1] = '\0';
}
return q;
}
/* Initialize Python readline support. */
void
gdbpy_initialize_gdb_readline (void)
{
/* Python's readline module conflicts with GDB's use of readline
since readline is not reentrant. Ideally, a reentrant wrapper to
GDB's readline should be implemented to replace Python's readline
and prevent conflicts. For now, this file implements a
sys.meta_path finder that simply fails to import the readline
module. */
* python/py-arch.c (gdbpy_initialize_arch): Return 'int'. Check errors. * python/py-auto-load.c (gdbpy_initialize_auto_load): Return 'int'. * python/py-block.c (gdbpy_initialize_blocks): Return 'int'. Check errors. * python/py-breakpoint.c (gdbpy_initialize_breakpoints): Return 'int'. Check errors. * python/py-cmd.c (gdbpy_initialize_commands): Return 'int'. Check errors. * python/py-event.c (gdbpy_initialize_event): Return 'int'. Check errors. * python/py-event.h (GDBPY_NEW_EVENT_TYPE): Change generated init function to return 'int'. * python/py-evtregistry.c (gdbpy_initialize_eventregistry): Return 'int'. Check errors. * python/py-evts.c (gdbpy_initialize_py_events): Return 'int'. Check errors. * python/py-finishbreakpoint.c (gdbpy_initialize_finishbreakpoints): Return 'int'. Check errors. * python/py-frame.c (gdbpy_initialize_frames): Return 'int'. Check errors. * python/py-function.c (gdbpy_initialize_functions): Return 'int'. Check errors. * python/py-gdb-readline.c (gdbpy_initialize_gdb_readline): Check errors. * python/py-inferior.c (gdbpy_initialize_inferior): Return 'int'. Check errors. * python/py-infthread.c (gdbpy_initialize_thread): Return 'int'. Check errors. * python/py-lazy-string.c (gdbpy_initialize_lazy_string): Return 'int'. Check errors. * python/py-objfile.c (gdbpy_initialize_objfile): Return 'int'. Check errors. * python/py-param.c (gdbpy_initialize_parameters): Return 'int'. Check errors. * python/py-progspace.c (gdbpy_initialize_pspace): Return 'int'. Check errors. * python/py-symbol.c (gdbpy_initialize_symbols): Return 'int'. Check errors. * python/py-symtab.c (gdbpy_initialize_symtabs): Return 'int'. Check errors. * python/py-type.c (gdbpy_initialize_types): Return 'int'. Check errors. * python/py-value.c (gdbpy_initialize_values): Return 'int'. Check errors. * python/python-internal.h (gdbpy_initialize_auto_load, gdbpy_initialize_values, gdbpy_initialize_frames, gdbpy_initialize_symtabs, gdbpy_initialize_commands, gdbpy_initialize_symbols, gdbpy_initialize_symtabs, gdbpy_initialize_blocks, gdbpy_initialize_types, gdbpy_initialize_functions, gdbpy_initialize_pspace, gdbpy_initialize_objfile, gdbpy_initialize_breakpoints, gdbpy_initialize_finishbreakpoints, gdbpy_initialize_lazy_string, gdbpy_initialize_parameters, gdbpy_initialize_thread, gdbpy_initialize_inferior, gdbpy_initialize_eventregistry, gdbpy_initialize_event, gdbpy_initialize_py_events, gdbpy_initialize_stop_event, gdbpy_initialize_signal_event, gdbpy_initialize_breakpoint_event, gdbpy_initialize_continue_event, gdbpy_initialize_exited_event, gdbpy_initialize_thread_event, gdbpy_initialize_new_objfile_event, gdbpy_initialize_arch): Update. Use CPYCHECKER_NEGATIVE_RESULT_SETS_EXCEPTION. * python/python.c (gdb_python_initialized): New global. (gdbpy_initialize_events): Return 'int'. Check errors. (_initialize_python): Check errors. Set gdb_python_initialized.
2013-05-20 22:28:52 +02:00
if (PyRun_SimpleString ("\
import sys\n\
\n\
class GdbRemoveReadlineFinder:\n\
def find_module(self, fullname, path=None):\n\
if fullname == 'readline' and path is None:\n\
return self\n\
return None\n\
\n\
def load_module(self, fullname):\n\
raise ImportError('readline module disabled under GDB')\n\
\n\
sys.meta_path.append(GdbRemoveReadlineFinder())\n\
* python/py-arch.c (gdbpy_initialize_arch): Return 'int'. Check errors. * python/py-auto-load.c (gdbpy_initialize_auto_load): Return 'int'. * python/py-block.c (gdbpy_initialize_blocks): Return 'int'. Check errors. * python/py-breakpoint.c (gdbpy_initialize_breakpoints): Return 'int'. Check errors. * python/py-cmd.c (gdbpy_initialize_commands): Return 'int'. Check errors. * python/py-event.c (gdbpy_initialize_event): Return 'int'. Check errors. * python/py-event.h (GDBPY_NEW_EVENT_TYPE): Change generated init function to return 'int'. * python/py-evtregistry.c (gdbpy_initialize_eventregistry): Return 'int'. Check errors. * python/py-evts.c (gdbpy_initialize_py_events): Return 'int'. Check errors. * python/py-finishbreakpoint.c (gdbpy_initialize_finishbreakpoints): Return 'int'. Check errors. * python/py-frame.c (gdbpy_initialize_frames): Return 'int'. Check errors. * python/py-function.c (gdbpy_initialize_functions): Return 'int'. Check errors. * python/py-gdb-readline.c (gdbpy_initialize_gdb_readline): Check errors. * python/py-inferior.c (gdbpy_initialize_inferior): Return 'int'. Check errors. * python/py-infthread.c (gdbpy_initialize_thread): Return 'int'. Check errors. * python/py-lazy-string.c (gdbpy_initialize_lazy_string): Return 'int'. Check errors. * python/py-objfile.c (gdbpy_initialize_objfile): Return 'int'. Check errors. * python/py-param.c (gdbpy_initialize_parameters): Return 'int'. Check errors. * python/py-progspace.c (gdbpy_initialize_pspace): Return 'int'. Check errors. * python/py-symbol.c (gdbpy_initialize_symbols): Return 'int'. Check errors. * python/py-symtab.c (gdbpy_initialize_symtabs): Return 'int'. Check errors. * python/py-type.c (gdbpy_initialize_types): Return 'int'. Check errors. * python/py-value.c (gdbpy_initialize_values): Return 'int'. Check errors. * python/python-internal.h (gdbpy_initialize_auto_load, gdbpy_initialize_values, gdbpy_initialize_frames, gdbpy_initialize_symtabs, gdbpy_initialize_commands, gdbpy_initialize_symbols, gdbpy_initialize_symtabs, gdbpy_initialize_blocks, gdbpy_initialize_types, gdbpy_initialize_functions, gdbpy_initialize_pspace, gdbpy_initialize_objfile, gdbpy_initialize_breakpoints, gdbpy_initialize_finishbreakpoints, gdbpy_initialize_lazy_string, gdbpy_initialize_parameters, gdbpy_initialize_thread, gdbpy_initialize_inferior, gdbpy_initialize_eventregistry, gdbpy_initialize_event, gdbpy_initialize_py_events, gdbpy_initialize_stop_event, gdbpy_initialize_signal_event, gdbpy_initialize_breakpoint_event, gdbpy_initialize_continue_event, gdbpy_initialize_exited_event, gdbpy_initialize_thread_event, gdbpy_initialize_new_objfile_event, gdbpy_initialize_arch): Update. Use CPYCHECKER_NEGATIVE_RESULT_SETS_EXCEPTION. * python/python.c (gdb_python_initialized): New global. (gdbpy_initialize_events): Return 'int'. Check errors. (_initialize_python): Check errors. Set gdb_python_initialized.
2013-05-20 22:28:52 +02:00
") == 0)
PyOS_ReadlineFunctionPointer = gdbpy_readline_wrapper;
}