2009-02-06 21:33:59 +00:00
|
|
|
|
/* gdb commands implemented in Python
|
|
|
|
|
|
2015-01-01 09:32:14 +00:00
|
|
|
|
Copyright (C) 2008-2015 Free Software Foundation, Inc.
|
2009-02-06 21:33:59 +00:00
|
|
|
|
|
|
|
|
|
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"
|
* python/python-internal.h (struct language_defn): Declare.
(python_gdbarch, python_language): Likewise.
(ensure_python_env): Add prototype.
(make_cleanup_py_restore_gil): Remove prototype.
* python/python.c: Include "arch-utils.h", "value.h" and "language.h".
(python_gdbarch, python_language): New global variables.
(struct python_env): New data type.
(ensure_python_env, restore_python_env): New functions.
(eval_python_from_control_command): Call ensure_python_env to
install current architecture and language.
(python_command, gdbpy_new_objfile): Likewise.
* python/python-cmd.c: Include "arch-utils.h" and "language.h".
(cmdpy_destroyer, cmdpy_function, cmdpy_completer): Call
ensure_python_env.
* python/python-type.c (clean_up_objfile_types): Likewise.
* python/python-objfile.c: Include "language.h".
(clean_up_objfile): Call ensure_python_env.
* python/python-prettyprint.c (apply_val_pretty_printer): Likewise.
(apply_varobj_pretty_printer): Do not call PyGILState_Ensure.
* varobj.c (varobj_ensure_python_env): New helper function.
(varobj_get_display_hint, update_dynamic_varobj_children,
install_default_visualizer, varobj_set_visualizer, free_variable,
value_get_print_value): Call it.
(value_get_print_value): Add varobj argument instead of pretty
printer argument. Update all callers.
* python/python-utils.c (py_gil_restore, make_cleanup_py_restore_gil):
Remove.
* value.h (internal_function_fn): Add GDBARCH and LANGUAGE argument.
(call_internal_function): Likewise.
* value.c (call_internal_function): Likewise. Pass to handler.
* eval.c (evaluate_subexp_standard): Update call.
* python/python-function.c: Include "language.h".
(fnpy_call): Add GDBARCH and LANGAUAGE arguments and call
make_cleanup_python_env.
* python/python-value.c (builtin_type_pyint, builtin_type_pyfloat,
builtin_type_pylong, builtin_type_pybool, builtin_type_pychar,
valpy_str): Use python_gdbarch and python_language instead of
current_gdbarch and current_language.
* python/python-type.c (typy_lookup_typename): Likewise.
2009-07-02 17:04:23 +00:00
|
|
|
|
#include "arch-utils.h"
|
2009-02-06 21:33:59 +00:00
|
|
|
|
#include "value.h"
|
|
|
|
|
#include "python-internal.h"
|
|
|
|
|
#include "charset.h"
|
|
|
|
|
#include "gdbcmd.h"
|
|
|
|
|
#include "cli/cli-decode.h"
|
|
|
|
|
#include "completer.h"
|
* python/python-internal.h (struct language_defn): Declare.
(python_gdbarch, python_language): Likewise.
(ensure_python_env): Add prototype.
(make_cleanup_py_restore_gil): Remove prototype.
* python/python.c: Include "arch-utils.h", "value.h" and "language.h".
(python_gdbarch, python_language): New global variables.
(struct python_env): New data type.
(ensure_python_env, restore_python_env): New functions.
(eval_python_from_control_command): Call ensure_python_env to
install current architecture and language.
(python_command, gdbpy_new_objfile): Likewise.
* python/python-cmd.c: Include "arch-utils.h" and "language.h".
(cmdpy_destroyer, cmdpy_function, cmdpy_completer): Call
ensure_python_env.
* python/python-type.c (clean_up_objfile_types): Likewise.
* python/python-objfile.c: Include "language.h".
(clean_up_objfile): Call ensure_python_env.
* python/python-prettyprint.c (apply_val_pretty_printer): Likewise.
(apply_varobj_pretty_printer): Do not call PyGILState_Ensure.
* varobj.c (varobj_ensure_python_env): New helper function.
(varobj_get_display_hint, update_dynamic_varobj_children,
install_default_visualizer, varobj_set_visualizer, free_variable,
value_get_print_value): Call it.
(value_get_print_value): Add varobj argument instead of pretty
printer argument. Update all callers.
* python/python-utils.c (py_gil_restore, make_cleanup_py_restore_gil):
Remove.
* value.h (internal_function_fn): Add GDBARCH and LANGUAGE argument.
(call_internal_function): Likewise.
* value.c (call_internal_function): Likewise. Pass to handler.
* eval.c (evaluate_subexp_standard): Update call.
* python/python-function.c: Include "language.h".
(fnpy_call): Add GDBARCH and LANGAUAGE arguments and call
make_cleanup_python_env.
* python/python-value.c (builtin_type_pyint, builtin_type_pyfloat,
builtin_type_pylong, builtin_type_pybool, builtin_type_pychar,
valpy_str): Use python_gdbarch and python_language instead of
current_gdbarch and current_language.
* python/python-type.c (typy_lookup_typename): Likewise.
2009-07-02 17:04:23 +00:00
|
|
|
|
#include "language.h"
|
2009-02-06 21:33:59 +00:00
|
|
|
|
|
|
|
|
|
/* Struct representing built-in completion types. */
|
|
|
|
|
struct cmdpy_completer
|
|
|
|
|
{
|
2014-05-14 02:44:51 +00:00
|
|
|
|
/* Python symbol name.
|
|
|
|
|
This isn't a const char * for Python 2.4's sake.
|
|
|
|
|
PyModule_AddIntConstant only takes a char *, sigh. */
|
2009-02-06 21:33:59 +00:00
|
|
|
|
char *name;
|
|
|
|
|
/* Completion function. */
|
2012-06-13 15:41:24 +00:00
|
|
|
|
completer_ftype *completer;
|
2009-02-06 21:33:59 +00:00
|
|
|
|
};
|
|
|
|
|
|
2014-05-14 02:44:51 +00:00
|
|
|
|
static const struct cmdpy_completer completers[] =
|
2009-02-06 21:33:59 +00:00
|
|
|
|
{
|
|
|
|
|
{ "COMPLETE_NONE", noop_completer },
|
|
|
|
|
{ "COMPLETE_FILENAME", filename_completer },
|
|
|
|
|
{ "COMPLETE_LOCATION", location_completer },
|
|
|
|
|
{ "COMPLETE_COMMAND", command_completer },
|
|
|
|
|
{ "COMPLETE_SYMBOL", make_symbol_completion_list_fn },
|
2013-11-07 12:32:31 +00:00
|
|
|
|
{ "COMPLETE_EXPRESSION", expression_completer },
|
2009-02-06 21:33:59 +00:00
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#define N_COMPLETERS (sizeof (completers) / sizeof (completers[0]))
|
|
|
|
|
|
|
|
|
|
/* A gdb command. For the time being only ordinary commands (not
|
|
|
|
|
set/show commands) are allowed. */
|
|
|
|
|
struct cmdpy_object
|
|
|
|
|
{
|
|
|
|
|
PyObject_HEAD
|
|
|
|
|
|
|
|
|
|
/* The corresponding gdb command object, or NULL if the command is
|
|
|
|
|
no longer installed. */
|
|
|
|
|
struct cmd_list_element *command;
|
|
|
|
|
|
|
|
|
|
/* A prefix command requires storage for a list of its sub-commands.
|
|
|
|
|
A pointer to this is passed to add_prefix_command, and to add_cmd
|
|
|
|
|
for sub-commands of that prefix. If this Command is not a prefix
|
|
|
|
|
command, then this field is unused. */
|
|
|
|
|
struct cmd_list_element *sub_list;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
typedef struct cmdpy_object cmdpy_object;
|
|
|
|
|
|
Fix redefinition errors in C++ mode
In C, we can forward declare static structure instances. That doesn't
work in C++ though. C++ treats these as definitions. So then the
compiler complains about symbol redefinition, like:
src/gdb/elfread.c:1569:29: error: redefinition of ‘const sym_fns elf_sym_fns_lazy_psyms’
src/gdb/elfread.c:53:29: error: ‘const sym_fns elf_sym_fns_lazy_psyms’ previously declared here
The intent of static here is naturally to avoid making these objects
visible outside the compilation unit. The equivalent in C++ would be
to instead define the objects in the anonymous namespace. But given
that it's desirable to leave the codebase compiling as both C and C++
for a while, this just makes the objects extern.
(base_breakpoint_ops is already declared in breakpoint.h, so we can
just remove the forward declare from breakpoint.c)
gdb/ChangeLog:
2015-02-11 Tom Tromey <tromey@redhat.com>
Pedro Alves <palves@redhat.com>
* breakpoint.c (base_breakpoint_ops): Delete.
* dwarf2loc.c (dwarf_expr_ctx_funcs): Make extern.
* elfread.c (elf_sym_fns_gdb_index, elf_sym_fns_lazy_psyms): Make extern.
* guile/guile.c (guile_extension_script_ops, guile_extension_ops): Make extern.
* ppcnbsd-tdep.c (ppcnbsd2_sigtramp): Make extern.
* python/py-arch.c (arch_object_type): Make extern.
* python/py-block.c (block_syms_iterator_object_type): Make extern.
* python/py-bpevent.c (breakpoint_event_object_type): Make extern.
* python/py-cmd.c (cmdpy_object_type): Make extern.
* python/py-continueevent.c (continue_event_object_type)
* python/py-event.h (GDBPY_NEW_EVENT_TYPE): Remove 'qual'
parameter. Update all callers.
* python/py-evtregistry.c (eventregistry_object_type): Make extern.
* python/py-exitedevent.c (exited_event_object_type): Make extern.
* python/py-finishbreakpoint.c (finish_breakpoint_object_type): Make extern.
* python/py-function.c (fnpy_object_type): Make extern.
* python/py-inferior.c (inferior_object_type, membuf_object_type): Make extern.
* python/py-infevents.c (call_pre_event_object_type)
(inferior_call_post_event_object_type).
(memory_changed_event_object_type): Make extern.
* python/py-infthread.c (thread_object_type): Make extern.
* python/py-lazy-string.c (lazy_string_object_type): Make extern.
* python/py-linetable.c (linetable_entry_object_type)
(linetable_object_type, ltpy_iterator_object_type): Make extern.
* python/py-newobjfileevent.c (new_objfile_event_object_type)
(clear_objfiles_event_object_type): Make extern.
* python/py-objfile.c (objfile_object_type): Make extern.
* python/py-param.c (parmpy_object_type): Make extern.
* python/py-progspace.c (pspace_object_type): Make extern.
* python/py-signalevent.c (signal_event_object_type): Make extern.
* python/py-symtab.c (symtab_object_type, sal_object_type): Make extern.
* python/py-type.c (type_object_type, field_object_type)
(type_iterator_object_type): Make extern.
* python/python.c (python_extension_script_ops)
(python_extension_ops): Make extern.
* stap-probe.c (stap_probe_ops): Make extern.
2015-02-11 11:20:21 +00:00
|
|
|
|
extern PyTypeObject cmdpy_object_type
|
2013-05-20 20:09:01 +00:00
|
|
|
|
CPYCHECKER_TYPE_OBJECT_FOR_TYPEDEF ("cmdpy_object");
|
2009-02-06 21:33:59 +00:00
|
|
|
|
|
|
|
|
|
/* Constants used by this module. */
|
|
|
|
|
static PyObject *invoke_cst;
|
|
|
|
|
static PyObject *complete_cst;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* Python function which wraps dont_repeat. */
|
|
|
|
|
static PyObject *
|
|
|
|
|
cmdpy_dont_repeat (PyObject *self, PyObject *args)
|
|
|
|
|
{
|
|
|
|
|
dont_repeat ();
|
|
|
|
|
Py_RETURN_NONE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* Called if the gdb cmd_list_element is destroyed. */
|
2010-05-25 15:27:17 +00:00
|
|
|
|
|
2009-02-06 21:33:59 +00:00
|
|
|
|
static void
|
|
|
|
|
cmdpy_destroyer (struct cmd_list_element *self, void *context)
|
|
|
|
|
{
|
|
|
|
|
cmdpy_object *cmd;
|
* python/python-internal.h (struct language_defn): Declare.
(python_gdbarch, python_language): Likewise.
(ensure_python_env): Add prototype.
(make_cleanup_py_restore_gil): Remove prototype.
* python/python.c: Include "arch-utils.h", "value.h" and "language.h".
(python_gdbarch, python_language): New global variables.
(struct python_env): New data type.
(ensure_python_env, restore_python_env): New functions.
(eval_python_from_control_command): Call ensure_python_env to
install current architecture and language.
(python_command, gdbpy_new_objfile): Likewise.
* python/python-cmd.c: Include "arch-utils.h" and "language.h".
(cmdpy_destroyer, cmdpy_function, cmdpy_completer): Call
ensure_python_env.
* python/python-type.c (clean_up_objfile_types): Likewise.
* python/python-objfile.c: Include "language.h".
(clean_up_objfile): Call ensure_python_env.
* python/python-prettyprint.c (apply_val_pretty_printer): Likewise.
(apply_varobj_pretty_printer): Do not call PyGILState_Ensure.
* varobj.c (varobj_ensure_python_env): New helper function.
(varobj_get_display_hint, update_dynamic_varobj_children,
install_default_visualizer, varobj_set_visualizer, free_variable,
value_get_print_value): Call it.
(value_get_print_value): Add varobj argument instead of pretty
printer argument. Update all callers.
* python/python-utils.c (py_gil_restore, make_cleanup_py_restore_gil):
Remove.
* value.h (internal_function_fn): Add GDBARCH and LANGUAGE argument.
(call_internal_function): Likewise.
* value.c (call_internal_function): Likewise. Pass to handler.
* eval.c (evaluate_subexp_standard): Update call.
* python/python-function.c: Include "language.h".
(fnpy_call): Add GDBARCH and LANGAUAGE arguments and call
make_cleanup_python_env.
* python/python-value.c (builtin_type_pyint, builtin_type_pyfloat,
builtin_type_pylong, builtin_type_pybool, builtin_type_pychar,
valpy_str): Use python_gdbarch and python_language instead of
current_gdbarch and current_language.
* python/python-type.c (typy_lookup_typename): Likewise.
2009-07-02 17:04:23 +00:00
|
|
|
|
struct cleanup *cleanup;
|
2009-02-06 21:33:59 +00:00
|
|
|
|
|
* python/python-internal.h (struct language_defn): Declare.
(python_gdbarch, python_language): Likewise.
(ensure_python_env): Add prototype.
(make_cleanup_py_restore_gil): Remove prototype.
* python/python.c: Include "arch-utils.h", "value.h" and "language.h".
(python_gdbarch, python_language): New global variables.
(struct python_env): New data type.
(ensure_python_env, restore_python_env): New functions.
(eval_python_from_control_command): Call ensure_python_env to
install current architecture and language.
(python_command, gdbpy_new_objfile): Likewise.
* python/python-cmd.c: Include "arch-utils.h" and "language.h".
(cmdpy_destroyer, cmdpy_function, cmdpy_completer): Call
ensure_python_env.
* python/python-type.c (clean_up_objfile_types): Likewise.
* python/python-objfile.c: Include "language.h".
(clean_up_objfile): Call ensure_python_env.
* python/python-prettyprint.c (apply_val_pretty_printer): Likewise.
(apply_varobj_pretty_printer): Do not call PyGILState_Ensure.
* varobj.c (varobj_ensure_python_env): New helper function.
(varobj_get_display_hint, update_dynamic_varobj_children,
install_default_visualizer, varobj_set_visualizer, free_variable,
value_get_print_value): Call it.
(value_get_print_value): Add varobj argument instead of pretty
printer argument. Update all callers.
* python/python-utils.c (py_gil_restore, make_cleanup_py_restore_gil):
Remove.
* value.h (internal_function_fn): Add GDBARCH and LANGUAGE argument.
(call_internal_function): Likewise.
* value.c (call_internal_function): Likewise. Pass to handler.
* eval.c (evaluate_subexp_standard): Update call.
* python/python-function.c: Include "language.h".
(fnpy_call): Add GDBARCH and LANGAUAGE arguments and call
make_cleanup_python_env.
* python/python-value.c (builtin_type_pyint, builtin_type_pyfloat,
builtin_type_pylong, builtin_type_pybool, builtin_type_pychar,
valpy_str): Use python_gdbarch and python_language instead of
current_gdbarch and current_language.
* python/python-type.c (typy_lookup_typename): Likewise.
2009-07-02 17:04:23 +00:00
|
|
|
|
cleanup = ensure_python_env (get_current_arch (), current_language);
|
2009-02-06 21:33:59 +00:00
|
|
|
|
|
|
|
|
|
/* Release our hold on the command object. */
|
|
|
|
|
cmd = (cmdpy_object *) context;
|
|
|
|
|
cmd->command = NULL;
|
|
|
|
|
Py_DECREF (cmd);
|
|
|
|
|
|
|
|
|
|
/* We allocated the name, doc string, and perhaps the prefix
|
|
|
|
|
name. */
|
Constify strings in tracepoint.c, lookup_cmd and the completers.
This is sort of a continuation of Keith's parse_exp_1 constification
patch. It started out by undoing these bits:
@@ -754,9 +754,12 @@ validate_actionline (char **line, struct
tmp_p = p;
for (loc = t->base.loc; loc; loc = loc->next)
{
- p = tmp_p;
- exp = parse_exp_1 (&p, loc->address,
+ const char *q;
+
+ q = tmp_p;
+ exp = parse_exp_1 (&q, loc->address,
block_for_pc (loc->address), 1);
+ p = (char *) q;
and progressively making more things const upwards, fixing fallout,
rinse repeat, until GDB built again (--enable-targets=all).
That ended up constifying lookup_cmd/add_cmd and (lots of) friends,
and the completers.
I didn't try to constify the command hooks themselves, because I know
upfront there are commands that write to the command string argument,
and I think I managed to stop at a nice non-hacky split point already.
I think the only non-really-super-obvious changes are
tracepoint.c:validate_actionline, and tracepoint.c:trace_dump_actions.
The rest is just mostly about 'char *' => 'const char *', 'char **'=>
'const char **', and the occasional (e.g., deprecated_cmd_warning)
case of 'char **'=> 'const char *', where/when I noticed that nothing
actually cares about the pointer to pointer output.
Tested on x86_64 Fedora 17, native and gdbserver.
gdb/
2013-03-13 Pedro Alves <palves@redhat.com>
* ada-lang.c (struct add_partial_datum) <text, text0, word>: Make
fields const.
(ada_make_symbol_completion_list): Make "text0" parameter const.
* ax-gdb.c (agent_eval_command_one): Make "exp" parameter const.
* breakpoint.c (condition_completer): Make "text" and "word"
parameters const. Adjust.
(check_tracepoint_command): Adjust to validate_actionline
prototype change.
(catch_syscall_completer): Make "text" and "word" parameters
const.
* cli/cli-cmds.c (show_user): Make "comname" local const.
(valid_command_p): Make "command" parameter const.
(alias_command): Make "alias_prefix" and "command_prefix" locals
const.
* cli/cli-decode.c (add_cmd): Make "name" parameter const.
(add_alias_cmd): Make "name" and "oldname" parameters const.
Adjust. No longer make copy of OLDNAME.
(add_prefix_cmd, add_abbrev_prefix_cmd, add_set_or_show_cmd)
(add_setshow_cmd_full, add_setshow_enum_cmd)
(add_setshow_auto_boolean_cmd, add_setshow_boolean_cmd)
(add_setshow_filename_cmd, add_setshow_string_cmd)
(add_setshow_string_noescape_cmd)
(add_setshow_optional_filename_cmd, add_setshow_integer_cmd)
(add_setshow_uinteger_cmd, add_setshow_zinteger_cmd)
(add_setshow_zuinteger_unlimited_cmd, add_setshow_zuinteger_cmd)
(delete_cmd, add_info, add_info_alias, add_com, add_com_alias):
Make "name" parameter const.
(help_cmd): Rename "command" parameter to "arg". New const local
"command".
(find_cmd): Make "command" parameter const.
(lookup_cmd_1): Make "text" parameter pointer to const. Adjust to
deprecated_cmd_warning prototype change.
(undef_cmd_error): Make "cmdtype" parameter const.
(lookup_cmd): Make "line" parameter const.
(deprecated_cmd_warning): Change type of "text" parameter to
pointer to const char, from pointer to pointer to char. Adjust.
(lookup_cmd_composition): Make "text" parameter const.
(complete_on_cmdlist, complete_on_enum): Make "text" and "word"
parameters const.
* cli/cli-decode.h (struct cmd_list_element) <name>: Make field
const.
* cli/cli-script.c (validate_comname): Make "tem" local const.
(define_command): New const local "tem_c". Use it in calls to
lookup_cmd.
(document_command): Make "tem" and "comfull" locals const.
(show_user_1): Make "prefix" and "name" parameters const.
* cli-script.h (show_user_1): Make "prefix" and "name" parameters
const.
* command.h (add_cmd, add_alias_cmd, add_prefix_cmd)
(add_abbrev_prefix_cmd, completer_ftype, lookup_cmd, lookup_cmd_1)
(deprecated_cmd_warning, lookup_cmd_composition, add_com)
(add_com_alias, add_info, add_info_alias, complete_on_cmdlist)
(complete_on_enum, add_setshow_enum_cmd)
(add_setshow_auto_boolean_cmd, add_setshow_boolean_cmd)
(add_setshow_filename_cmd, add_setshow_string_cmd)
(add_setshow_string_noescape_cmd)
(add_setshow_optional_filename_cmd, add_setshow_integer_cmd)
(add_setshow_uinteger_cmd, add_setshow_zinteger_cmd)
(add_setshow_zuinteger_cmd, add_setshow_zuinteger_unlimited_cmd):
Change prototypes, constifying strings.
* completer.c (noop_completer, filename_completer): Make "text"
and "prefix" parameters const.
(location_completer, expression_completer)
(complete_line_internal): Make "text" and "prefix" parameters
const and adjust.
(command_completer, signal_completer): Make "text" and "prefix"
parameters const.
* completer.h (noop_completer, filename_completer)
(expression_completer, location_completer, command_completer)
(signal_completer): Change prototypes.
* corefile.c (complete_set_gnutarget): Make "text" and "word"
parameters const.
* cp-abi.c (cp_abi_completer): Likewise.
* expression.h (parse_expression_for_completion): Change
prototype.
* f-lang.c (f_make_symbol_completion_list): Make "text" and "word"
parameters const.
* infcmd.c (_initialize_infcmd): Make "cmd_name" local const.
* infrun.c (handle_completer): Make "text" and "word" parameters
const.
* interps.c (interpreter_completer): Make "text" and "word"
parameters const.
* language.h (struct language_defn)
<la_make_symbol_completion_list>: Make "text" and "word"
parameters const.
* parse.c (parse_exp_1): Move const hack to parse_exp_in_context.
(parse_exp_in_context): Rename to ...
(parse_exp_in_context_1): ... this.
(parse_exp_in_context): Reimplement, with const hack from
parse_exp_1.
(parse_expression_for_completion): Make "string" parameter const.
* printcmd.c (decode_format): Make "string_ptr" parameter pointer
to pointer to const char. Adjust.
(print_command_1): Make "exp" parameter const.
(output_command): Rename to ...
(output_command_const): ... this. Make "exp" parameter const.
(output_command): Reimplement.
(x_command): Adjust.
(display_command): Rename "exp" parameter to "arg". New "exp"
local, const version of "arg".
* python/py-auto-load.c (gdbpy_initialize_auto_load): Make
"cmd_name" local const.
* python/py-cmd.c (cmdpy_destroyer): Cast const away in xfree
call.
(cmdpy_completer): Make "text" and "word" parameters const.
(gdbpy_parse_command_name): Make "prefix_text2" local const.
* python/py-param.c (add_setshow_generic): Make "tmp_name" local
const.
* remote.c (_initialize_remote): Make "cmd_name" local const.
* symtab.c (language_search_unquoted_string): Make "text" and "p"
parameters const. Adjust.
(completion_list_add_fields): Make "sym_text", "text" and "word"
parameters const.
(struct add_name_data) <sym_text, text, word>: Make fields const.
(default_make_symbol_completion_list_break_on): Make "text" and
"word" parameters const. Adjust locals.
(default_make_symbol_completion_list)
(make_symbol_completion_list, make_symbol_completion_type)
(make_symbol_completion_list_fn): Make "text" and "word"
parameters const.
(make_file_symbol_completion_list): Make "text", "word" and
"srcfile" parameters const. Adjust locals.
(add_filename_to_list): Make "text" and "word" parameters const.
(struct add_partial_filename_data) <text, word>: Make fields
const.
(make_source_files_completion_list): Make "text" and "word"
parameters const.
* symtab.h (default_make_symbol_completion_list_break_on)
(default_make_symbol_completion_list, make_symbol_completion_list)
(make_symbol_completion_type enum type_code)
(make_symbol_completion_list_fn make_file_symbol_completion_list)
(make_source_files_completion_list): Change prototype.
* top.c (execute_command): Adjust to pass pointer to pointer to
const char to lookup_cmd, and to deprecated_cmd_warning prototype
change.
(set_verbose): Make "cmdname" local const.
* tracepoint.c (decode_agent_options): Make "exp" parameter const,
and adjust.
(validate_actionline): Make "line" parameter a pointer to const
char, and adjust.
(encode_actions_1): Make "action_exp" local const, and adjust.
(encode_actions): Adjust.
(replace_comma): Delete.
(trace_dump_actions): Make "action_exp" and "next_comma" locals
const, and adjust. Don't frob the action string while splitting
it at commas. Instead, make a copy of each split substring in
turn.
(trace_dump_command): Adjust to validate_actionline prototype
change.
* tracepoint.h (decode_agent_options, decode_agent_options)
(encode_actions, validate_actionline): Change prototypes.
* valprint.h (output_command): Delete declaration.
(output_command_const): Declare.
* value.c (function_destroyer): Cast const away in xfree call.
2013-03-13 18:34:55 +00:00
|
|
|
|
xfree ((char *) self->name);
|
2014-07-22 02:55:16 +00:00
|
|
|
|
xfree ((char *) self->doc);
|
2014-07-22 02:43:04 +00:00
|
|
|
|
xfree ((char *) self->prefixname);
|
2009-02-06 21:33:59 +00:00
|
|
|
|
|
* python/python-internal.h (struct language_defn): Declare.
(python_gdbarch, python_language): Likewise.
(ensure_python_env): Add prototype.
(make_cleanup_py_restore_gil): Remove prototype.
* python/python.c: Include "arch-utils.h", "value.h" and "language.h".
(python_gdbarch, python_language): New global variables.
(struct python_env): New data type.
(ensure_python_env, restore_python_env): New functions.
(eval_python_from_control_command): Call ensure_python_env to
install current architecture and language.
(python_command, gdbpy_new_objfile): Likewise.
* python/python-cmd.c: Include "arch-utils.h" and "language.h".
(cmdpy_destroyer, cmdpy_function, cmdpy_completer): Call
ensure_python_env.
* python/python-type.c (clean_up_objfile_types): Likewise.
* python/python-objfile.c: Include "language.h".
(clean_up_objfile): Call ensure_python_env.
* python/python-prettyprint.c (apply_val_pretty_printer): Likewise.
(apply_varobj_pretty_printer): Do not call PyGILState_Ensure.
* varobj.c (varobj_ensure_python_env): New helper function.
(varobj_get_display_hint, update_dynamic_varobj_children,
install_default_visualizer, varobj_set_visualizer, free_variable,
value_get_print_value): Call it.
(value_get_print_value): Add varobj argument instead of pretty
printer argument. Update all callers.
* python/python-utils.c (py_gil_restore, make_cleanup_py_restore_gil):
Remove.
* value.h (internal_function_fn): Add GDBARCH and LANGUAGE argument.
(call_internal_function): Likewise.
* value.c (call_internal_function): Likewise. Pass to handler.
* eval.c (evaluate_subexp_standard): Update call.
* python/python-function.c: Include "language.h".
(fnpy_call): Add GDBARCH and LANGAUAGE arguments and call
make_cleanup_python_env.
* python/python-value.c (builtin_type_pyint, builtin_type_pyfloat,
builtin_type_pylong, builtin_type_pybool, builtin_type_pychar,
valpy_str): Use python_gdbarch and python_language instead of
current_gdbarch and current_language.
* python/python-type.c (typy_lookup_typename): Likewise.
2009-07-02 17:04:23 +00:00
|
|
|
|
do_cleanups (cleanup);
|
2009-02-06 21:33:59 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Called by gdb to invoke the command. */
|
2010-05-25 15:27:17 +00:00
|
|
|
|
|
2009-02-06 21:33:59 +00:00
|
|
|
|
static void
|
|
|
|
|
cmdpy_function (struct cmd_list_element *command, char *args, int from_tty)
|
|
|
|
|
{
|
|
|
|
|
cmdpy_object *obj = (cmdpy_object *) get_cmd_context (command);
|
|
|
|
|
PyObject *argobj, *ttyobj, *result;
|
|
|
|
|
struct cleanup *cleanup;
|
|
|
|
|
|
* python/python-internal.h (struct language_defn): Declare.
(python_gdbarch, python_language): Likewise.
(ensure_python_env): Add prototype.
(make_cleanup_py_restore_gil): Remove prototype.
* python/python.c: Include "arch-utils.h", "value.h" and "language.h".
(python_gdbarch, python_language): New global variables.
(struct python_env): New data type.
(ensure_python_env, restore_python_env): New functions.
(eval_python_from_control_command): Call ensure_python_env to
install current architecture and language.
(python_command, gdbpy_new_objfile): Likewise.
* python/python-cmd.c: Include "arch-utils.h" and "language.h".
(cmdpy_destroyer, cmdpy_function, cmdpy_completer): Call
ensure_python_env.
* python/python-type.c (clean_up_objfile_types): Likewise.
* python/python-objfile.c: Include "language.h".
(clean_up_objfile): Call ensure_python_env.
* python/python-prettyprint.c (apply_val_pretty_printer): Likewise.
(apply_varobj_pretty_printer): Do not call PyGILState_Ensure.
* varobj.c (varobj_ensure_python_env): New helper function.
(varobj_get_display_hint, update_dynamic_varobj_children,
install_default_visualizer, varobj_set_visualizer, free_variable,
value_get_print_value): Call it.
(value_get_print_value): Add varobj argument instead of pretty
printer argument. Update all callers.
* python/python-utils.c (py_gil_restore, make_cleanup_py_restore_gil):
Remove.
* value.h (internal_function_fn): Add GDBARCH and LANGUAGE argument.
(call_internal_function): Likewise.
* value.c (call_internal_function): Likewise. Pass to handler.
* eval.c (evaluate_subexp_standard): Update call.
* python/python-function.c: Include "language.h".
(fnpy_call): Add GDBARCH and LANGAUAGE arguments and call
make_cleanup_python_env.
* python/python-value.c (builtin_type_pyint, builtin_type_pyfloat,
builtin_type_pylong, builtin_type_pybool, builtin_type_pychar,
valpy_str): Use python_gdbarch and python_language instead of
current_gdbarch and current_language.
* python/python-type.c (typy_lookup_typename): Likewise.
2009-07-02 17:04:23 +00:00
|
|
|
|
cleanup = ensure_python_env (get_current_arch (), current_language);
|
2009-02-06 21:33:59 +00:00
|
|
|
|
|
|
|
|
|
if (! obj)
|
|
|
|
|
error (_("Invalid invocation of Python command object."));
|
|
|
|
|
if (! PyObject_HasAttr ((PyObject *) obj, invoke_cst))
|
|
|
|
|
{
|
|
|
|
|
if (obj->command->prefixname)
|
|
|
|
|
{
|
|
|
|
|
/* A prefix command does not need an invoke method. */
|
|
|
|
|
do_cleanups (cleanup);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
error (_("Python command object missing 'invoke' method."));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (! args)
|
|
|
|
|
args = "";
|
|
|
|
|
argobj = PyUnicode_Decode (args, strlen (args), host_charset (), NULL);
|
|
|
|
|
if (! argobj)
|
2010-10-13 13:24:40 +00:00
|
|
|
|
{
|
|
|
|
|
gdbpy_print_stack ();
|
|
|
|
|
error (_("Could not convert arguments to Python string."));
|
|
|
|
|
}
|
2009-02-06 21:33:59 +00:00
|
|
|
|
|
|
|
|
|
ttyobj = from_tty ? Py_True : Py_False;
|
|
|
|
|
Py_INCREF (ttyobj);
|
|
|
|
|
result = PyObject_CallMethodObjArgs ((PyObject *) obj, invoke_cst, argobj,
|
|
|
|
|
ttyobj, NULL);
|
|
|
|
|
Py_DECREF (argobj);
|
|
|
|
|
Py_DECREF (ttyobj);
|
2010-05-25 15:27:17 +00:00
|
|
|
|
|
2009-02-06 21:33:59 +00:00
|
|
|
|
if (! result)
|
|
|
|
|
{
|
|
|
|
|
PyObject *ptype, *pvalue, *ptraceback;
|
2010-05-25 15:27:17 +00:00
|
|
|
|
char *msg;
|
2009-02-06 21:33:59 +00:00
|
|
|
|
|
|
|
|
|
PyErr_Fetch (&ptype, &pvalue, &ptraceback);
|
|
|
|
|
|
2010-05-25 15:27:17 +00:00
|
|
|
|
/* Try to fetch an error message contained within ptype, pvalue.
|
|
|
|
|
When fetching the error message we need to make our own copy,
|
|
|
|
|
we no longer own ptype, pvalue after the call to PyErr_Restore. */
|
2009-02-06 21:33:59 +00:00
|
|
|
|
|
2010-05-25 15:27:17 +00:00
|
|
|
|
msg = gdbpy_exception_to_string (ptype, pvalue);
|
|
|
|
|
make_cleanup (xfree, msg);
|
|
|
|
|
|
|
|
|
|
if (msg == NULL)
|
|
|
|
|
{
|
|
|
|
|
/* An error occurred computing the string representation of the
|
|
|
|
|
error message. This is rare, but we should inform the user. */
|
|
|
|
|
printf_filtered (_("An error occurred in a Python command\n"
|
2011-01-06 00:57:05 +00:00
|
|
|
|
"and then another occurred computing the "
|
|
|
|
|
"error message.\n"));
|
2009-02-06 21:33:59 +00:00
|
|
|
|
gdbpy_print_stack ();
|
|
|
|
|
}
|
2010-05-25 15:27:17 +00:00
|
|
|
|
|
|
|
|
|
/* Don't print the stack for gdb.GdbError exceptions.
|
|
|
|
|
It is generally used to flag user errors.
|
|
|
|
|
|
|
|
|
|
We also don't want to print "Error occurred in Python command"
|
|
|
|
|
for user errors. However, a missing message for gdb.GdbError
|
|
|
|
|
exceptions is arguably a bug, so we flag it as such. */
|
|
|
|
|
|
|
|
|
|
if (! PyErr_GivenExceptionMatches (ptype, gdbpy_gdberror_exc)
|
|
|
|
|
|| msg == NULL || *msg == '\0')
|
2009-02-06 21:33:59 +00:00
|
|
|
|
{
|
|
|
|
|
PyErr_Restore (ptype, pvalue, ptraceback);
|
|
|
|
|
gdbpy_print_stack ();
|
2010-05-25 15:27:17 +00:00
|
|
|
|
if (msg != NULL && *msg != '\0')
|
|
|
|
|
error (_("Error occurred in Python command: %s"), msg);
|
|
|
|
|
else
|
|
|
|
|
error (_("Error occurred in Python command."));
|
2009-02-06 21:33:59 +00:00
|
|
|
|
}
|
2010-05-25 15:27:17 +00:00
|
|
|
|
else
|
2010-10-19 20:11:37 +00:00
|
|
|
|
{
|
|
|
|
|
Py_XDECREF (ptype);
|
|
|
|
|
Py_XDECREF (pvalue);
|
|
|
|
|
Py_XDECREF (ptraceback);
|
|
|
|
|
error ("%s", msg);
|
|
|
|
|
}
|
2009-02-06 21:33:59 +00:00
|
|
|
|
}
|
2010-05-25 15:27:17 +00:00
|
|
|
|
|
2009-02-06 21:33:59 +00:00
|
|
|
|
Py_DECREF (result);
|
|
|
|
|
do_cleanups (cleanup);
|
|
|
|
|
}
|
|
|
|
|
|
PR python/16699: GDB Python command completion with overriden complete vs. completer class
This PR came from a Red Hat bug that was filed recently. I checked and
it still exists on HEAD, so here's a proposed fix. Although this is
marked as a Python backend bug, this is really about the completion
mechanism used by GDB. Since this code reminds me of my first attempt
to make a good noodle, it took me quite some time to fix it in a
non-intrusive way.
The problem is triggered when one registers a completion method inside a
class in a Python script, rather than registering the command using a
completer class directly. For example, consider the following script:
class MyFirstCommand(gdb.Command):
def __init__(self):
gdb.Command.__init__(self,'myfirstcommand',gdb.COMMAND_USER,gdb.COMPLETE_FILENAME)
def invoke(self,argument,from_tty):
raise gdb.GdbError('not implemented')
class MySecondCommand(gdb.Command):
def __init__(self):
gdb.Command.__init__(self,'mysecondcommand',gdb.COMMAND_USER)
def invoke(self,argument,from_tty):
raise gdb.GdbError('not implemented')
def complete(self,text,word):
return gdb.COMPLETE_FILENAME
MyFirstCommand ()
MySecondCommand ()
When one loads this into GDB and tries to complete filenames for both
myfirstcommand and mysecondcommand, she gets:
(gdb) myfirstcommand /hom<TAB>
(gdb) myfirstcommand /home/
^
...
(gdb) mysecondcommand /hom<TAB>
(gdb) mysecondcommand /home
^
(The "^" marks the final position of the cursor after the TAB).
So we see that myfirstcommand honors the COMPLETE_FILENAME class (as
specified in the command creation), but mysecondcommand does not. After
some investigation, I found that the problem lies with the set of word
break characters that is used for each case. The set should be the same
for both commands, but it is not.
During the process of deciding which type of completion should be used,
the code in gdb/completer.c:complete_line_internal analyses the command
that requested the completion and tries to determine the type of
completion wanted by checking which completion function will be called
(e.g., filename_completer for filenames, location_completer for
locations, etc.).
This all works fine for myfirstcommand, because immediately after the
command registration the Python backend already sets its completion
function to filename_completer (which then causes the
complete_line_internal function to choose the right set of word break
chars). However, for mysecondcommand, this decision is postponed to
when the completer function is evaluated, and the Python backend uses an
internal completer (called cmdpy_completer). complete_line_internal
doesn't know about this internal completer, and can't choose the right
set of word break chars in time, which then leads to a bad decision when
completing the "/hom" word.
So, after a few attempts, I decided to create another callback in
"struct cmd_list_element" that will be responsible for handling the case
when there is an unknown completer function for complete_line_internal
to work with. So far, only the Python backend uses this callback, and
only when the user provides a completer method instead of registering
the command directly with a completer class. I think this is the best
option because it not very intrusive (all the other commands will still
work normally), but especially because the whole completion code is so
messy that it would be hard to fix this without having to redesign
things.
I have regtested this on Fedora 18 x86_64, without regressions. I also
included a testcase.
gdb/ChangeLog:
2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* cli/cli-decode.c (set_cmd_completer_handle_brkchars): New
function.
(add_cmd): Set "completer_handle_brkchars" to NULL.
* cli/cli-decode.h (struct cmd_list_element)
<completer_handle_brkchars>: New field.
* command.h (completer_ftype_void): New typedef.
(set_cmd_completer_handle_brkchars): New prototype.
* completer.c (set_gdb_completion_word_break_characters): New
function.
(complete_line_internal): Call "completer_handle_brkchars"
callback from command.
* completer.h: Include "command.h".
(set_gdb_completion_word_break_characters): New prototype.
* python/py-cmd.c (cmdpy_completer_helper): New function.
(cmdpy_completer_handle_brkchars): New function.
(cmdpy_completer): Adjust to use cmdpy_completer_helper.
(cmdpy_init): Set completer_handle_brkchars to
cmdpy_completer_handle_brkchars.
gdb/testsuite/ChangeLog:
2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* gdb.python/py-completion.exp: New file.
* gdb.python/py-completion.py: Likewise.
2014-09-03 20:30:28 +00:00
|
|
|
|
/* Helper function for the Python command completers (both "pure"
|
|
|
|
|
completer and brkchar handler). This function takes COMMAND, TEXT
|
|
|
|
|
and WORD and tries to call the Python method for completion with
|
Fix Python completion when using the "complete" command
This patch is related to PR python/16699, and is an improvement over the
patch posted here:
<https://sourceware.org/ml/gdb-patches/2014-03/msg00301.html>
Keith noticed that, when using the "complete" command on GDB to complete
a Python command, some strange things could happen. In order to
understand what can go wrong, I need to explain how the Python
completion mechanism works.
When the user requests a completion of a Python command by using TAB,
GDB will first try to determine the right set of "brkchars" that will be
used when doing the completion. This is done by actually calling the
"complete" method of the Python class. Then, when we already know the
"brkchars" that will be used, we call the "complete" method again, for
the same values.
If you read the thread mentioned above, you will see that one of the
design decisions was to make the "cmdpy_completer_helper" (which is the
function the does the actual calling of the "complete" method) cache the
first result of the completion, since this result will be used in the
second call, to do the actual completion.
The problem is that the "complete" command does not process the
brkchars, and the current Python completion mechanism (improved by the
patch mentioned above) relies on GDB trying to determine the brkchars,
and then doing the completion itself. Therefore, when we use the
"complete" command instead of doing a TAB-completion on GDB, there is a
scenario where we can use the invalid cache of a previous Python command
that was completed before. For example:
(gdb) A <TAB>
(gdb) complete B
B value1
B value10
B value2
B value3
B value4
B value5
B value6
B value7
B value8
B value9
(gdb) B <TAB>
comp1 comp2 comp4 comp6 comp8
comp10 comp3 comp5 comp7 comp9
Here, we see that "complete B " gave a different result than "B <TAB>".
The reason for that is because "A <TAB>" was called before, and its
completion results were "value*", so when GDB tried to "complete B " it
wrongly answered with the results for A. The problem here is using a
wrong cache (A's cache) for completing B.
We tried to come up with a solution that would preserve the caching
mechanism, but it wasn't really possible. So I decided to completely
remove the cache, and doing the method calling twice for every
completion. This is not optimal, but I do not think it will impact
users noticeably.
It is worth mentioning another small issue that I found. The code was
doing:
wordobj = PyUnicode_Decode (word, sizeof (word), host_charset (), NULL);
which is totally wrong, because using "sizeof" here will lead to always
the same result. So I changed this to use "strlen". The testcase also
catches this problem.
Keith kindly expanded the existing testcase to cover the problem
described above, and everything is passing.
gdb/ChangeLog:
2015-04-08 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* python/py-cmd.c (cmdpy_completer_helper): Adjust function to not
use a caching mechanism. Adjust comments and code to reflect
that. Replace 'sizeof' by 'strlen' when fetching 'wordobj'.
(cmdpy_completer_handle_brkchars): Adjust call to
cmdpy_completer_helper. Call Py_XDECREF for 'resultobj'.
(cmdpy_completer): Likewise.
gdb/testsuite/ChangeLog:
2015-04-08 Keith Seitz <keiths@redhat.com>
PR python/16699
* gdb.python/py-completion.exp: New tests for completion.
* gdb.python/py-completion.py (CompleteLimit1): New class.
(CompleteLimit2): Likewise.
(CompleteLimit3): Likewise.
(CompleteLimit4): Likewise.
(CompleteLimit5): Likewise.
(CompleteLimit6): Likewise.
(CompleteLimit7): Likewise.
2015-04-08 22:27:10 +00:00
|
|
|
|
these arguments.
|
|
|
|
|
|
|
|
|
|
This function is usually called twice: once when we are figuring out
|
|
|
|
|
the break characters to be used, and another to perform the real
|
|
|
|
|
completion itself. The reason for this two step dance is that we
|
|
|
|
|
need to know the set of "brkchars" to use early on, before we
|
|
|
|
|
actually try to perform the completion. But if a Python command
|
|
|
|
|
supplies a "complete" method then we have to call that method
|
|
|
|
|
first: it may return as its result the kind of completion to
|
|
|
|
|
perform and that will in turn specify which brkchars to use. IOW,
|
|
|
|
|
we need the result of the "complete" method before we actually
|
|
|
|
|
perform the completion. The only situation when this function is
|
|
|
|
|
not called twice is when the user uses the "complete" command: in
|
|
|
|
|
this scenario, there is no call to determine the "brkchars".
|
|
|
|
|
|
|
|
|
|
Ideally, it would be nice to cache the result of the first call (to
|
|
|
|
|
determine the "brkchars") and return this value directly in the
|
|
|
|
|
second call (to perform the actual completion). However, due to
|
|
|
|
|
the peculiarity of the "complete" command mentioned above, it is
|
|
|
|
|
possible to put GDB in a bad state if you perform a TAB-completion
|
|
|
|
|
and then a "complete"-completion sequentially. Therefore, we just
|
|
|
|
|
recalculate everything twice for TAB-completions.
|
PR python/16699: GDB Python command completion with overriden complete vs. completer class
This PR came from a Red Hat bug that was filed recently. I checked and
it still exists on HEAD, so here's a proposed fix. Although this is
marked as a Python backend bug, this is really about the completion
mechanism used by GDB. Since this code reminds me of my first attempt
to make a good noodle, it took me quite some time to fix it in a
non-intrusive way.
The problem is triggered when one registers a completion method inside a
class in a Python script, rather than registering the command using a
completer class directly. For example, consider the following script:
class MyFirstCommand(gdb.Command):
def __init__(self):
gdb.Command.__init__(self,'myfirstcommand',gdb.COMMAND_USER,gdb.COMPLETE_FILENAME)
def invoke(self,argument,from_tty):
raise gdb.GdbError('not implemented')
class MySecondCommand(gdb.Command):
def __init__(self):
gdb.Command.__init__(self,'mysecondcommand',gdb.COMMAND_USER)
def invoke(self,argument,from_tty):
raise gdb.GdbError('not implemented')
def complete(self,text,word):
return gdb.COMPLETE_FILENAME
MyFirstCommand ()
MySecondCommand ()
When one loads this into GDB and tries to complete filenames for both
myfirstcommand and mysecondcommand, she gets:
(gdb) myfirstcommand /hom<TAB>
(gdb) myfirstcommand /home/
^
...
(gdb) mysecondcommand /hom<TAB>
(gdb) mysecondcommand /home
^
(The "^" marks the final position of the cursor after the TAB).
So we see that myfirstcommand honors the COMPLETE_FILENAME class (as
specified in the command creation), but mysecondcommand does not. After
some investigation, I found that the problem lies with the set of word
break characters that is used for each case. The set should be the same
for both commands, but it is not.
During the process of deciding which type of completion should be used,
the code in gdb/completer.c:complete_line_internal analyses the command
that requested the completion and tries to determine the type of
completion wanted by checking which completion function will be called
(e.g., filename_completer for filenames, location_completer for
locations, etc.).
This all works fine for myfirstcommand, because immediately after the
command registration the Python backend already sets its completion
function to filename_completer (which then causes the
complete_line_internal function to choose the right set of word break
chars). However, for mysecondcommand, this decision is postponed to
when the completer function is evaluated, and the Python backend uses an
internal completer (called cmdpy_completer). complete_line_internal
doesn't know about this internal completer, and can't choose the right
set of word break chars in time, which then leads to a bad decision when
completing the "/hom" word.
So, after a few attempts, I decided to create another callback in
"struct cmd_list_element" that will be responsible for handling the case
when there is an unknown completer function for complete_line_internal
to work with. So far, only the Python backend uses this callback, and
only when the user provides a completer method instead of registering
the command directly with a completer class. I think this is the best
option because it not very intrusive (all the other commands will still
work normally), but especially because the whole completion code is so
messy that it would be hard to fix this without having to redesign
things.
I have regtested this on Fedora 18 x86_64, without regressions. I also
included a testcase.
gdb/ChangeLog:
2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* cli/cli-decode.c (set_cmd_completer_handle_brkchars): New
function.
(add_cmd): Set "completer_handle_brkchars" to NULL.
* cli/cli-decode.h (struct cmd_list_element)
<completer_handle_brkchars>: New field.
* command.h (completer_ftype_void): New typedef.
(set_cmd_completer_handle_brkchars): New prototype.
* completer.c (set_gdb_completion_word_break_characters): New
function.
(complete_line_internal): Call "completer_handle_brkchars"
callback from command.
* completer.h: Include "command.h".
(set_gdb_completion_word_break_characters): New prototype.
* python/py-cmd.c (cmdpy_completer_helper): New function.
(cmdpy_completer_handle_brkchars): New function.
(cmdpy_completer): Adjust to use cmdpy_completer_helper.
(cmdpy_init): Set completer_handle_brkchars to
cmdpy_completer_handle_brkchars.
gdb/testsuite/ChangeLog:
2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* gdb.python/py-completion.exp: New file.
* gdb.python/py-completion.py: Likewise.
2014-09-03 20:30:28 +00:00
|
|
|
|
|
|
|
|
|
This function returns the PyObject representing the Python method
|
|
|
|
|
call. */
|
|
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
|
cmdpy_completer_helper (struct cmd_list_element *command,
|
Fix Python completion when using the "complete" command
This patch is related to PR python/16699, and is an improvement over the
patch posted here:
<https://sourceware.org/ml/gdb-patches/2014-03/msg00301.html>
Keith noticed that, when using the "complete" command on GDB to complete
a Python command, some strange things could happen. In order to
understand what can go wrong, I need to explain how the Python
completion mechanism works.
When the user requests a completion of a Python command by using TAB,
GDB will first try to determine the right set of "brkchars" that will be
used when doing the completion. This is done by actually calling the
"complete" method of the Python class. Then, when we already know the
"brkchars" that will be used, we call the "complete" method again, for
the same values.
If you read the thread mentioned above, you will see that one of the
design decisions was to make the "cmdpy_completer_helper" (which is the
function the does the actual calling of the "complete" method) cache the
first result of the completion, since this result will be used in the
second call, to do the actual completion.
The problem is that the "complete" command does not process the
brkchars, and the current Python completion mechanism (improved by the
patch mentioned above) relies on GDB trying to determine the brkchars,
and then doing the completion itself. Therefore, when we use the
"complete" command instead of doing a TAB-completion on GDB, there is a
scenario where we can use the invalid cache of a previous Python command
that was completed before. For example:
(gdb) A <TAB>
(gdb) complete B
B value1
B value10
B value2
B value3
B value4
B value5
B value6
B value7
B value8
B value9
(gdb) B <TAB>
comp1 comp2 comp4 comp6 comp8
comp10 comp3 comp5 comp7 comp9
Here, we see that "complete B " gave a different result than "B <TAB>".
The reason for that is because "A <TAB>" was called before, and its
completion results were "value*", so when GDB tried to "complete B " it
wrongly answered with the results for A. The problem here is using a
wrong cache (A's cache) for completing B.
We tried to come up with a solution that would preserve the caching
mechanism, but it wasn't really possible. So I decided to completely
remove the cache, and doing the method calling twice for every
completion. This is not optimal, but I do not think it will impact
users noticeably.
It is worth mentioning another small issue that I found. The code was
doing:
wordobj = PyUnicode_Decode (word, sizeof (word), host_charset (), NULL);
which is totally wrong, because using "sizeof" here will lead to always
the same result. So I changed this to use "strlen". The testcase also
catches this problem.
Keith kindly expanded the existing testcase to cover the problem
described above, and everything is passing.
gdb/ChangeLog:
2015-04-08 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* python/py-cmd.c (cmdpy_completer_helper): Adjust function to not
use a caching mechanism. Adjust comments and code to reflect
that. Replace 'sizeof' by 'strlen' when fetching 'wordobj'.
(cmdpy_completer_handle_brkchars): Adjust call to
cmdpy_completer_helper. Call Py_XDECREF for 'resultobj'.
(cmdpy_completer): Likewise.
gdb/testsuite/ChangeLog:
2015-04-08 Keith Seitz <keiths@redhat.com>
PR python/16699
* gdb.python/py-completion.exp: New tests for completion.
* gdb.python/py-completion.py (CompleteLimit1): New class.
(CompleteLimit2): Likewise.
(CompleteLimit3): Likewise.
(CompleteLimit4): Likewise.
(CompleteLimit5): Likewise.
(CompleteLimit6): Likewise.
(CompleteLimit7): Likewise.
2015-04-08 22:27:10 +00:00
|
|
|
|
const char *text, const char *word)
|
PR python/16699: GDB Python command completion with overriden complete vs. completer class
This PR came from a Red Hat bug that was filed recently. I checked and
it still exists on HEAD, so here's a proposed fix. Although this is
marked as a Python backend bug, this is really about the completion
mechanism used by GDB. Since this code reminds me of my first attempt
to make a good noodle, it took me quite some time to fix it in a
non-intrusive way.
The problem is triggered when one registers a completion method inside a
class in a Python script, rather than registering the command using a
completer class directly. For example, consider the following script:
class MyFirstCommand(gdb.Command):
def __init__(self):
gdb.Command.__init__(self,'myfirstcommand',gdb.COMMAND_USER,gdb.COMPLETE_FILENAME)
def invoke(self,argument,from_tty):
raise gdb.GdbError('not implemented')
class MySecondCommand(gdb.Command):
def __init__(self):
gdb.Command.__init__(self,'mysecondcommand',gdb.COMMAND_USER)
def invoke(self,argument,from_tty):
raise gdb.GdbError('not implemented')
def complete(self,text,word):
return gdb.COMPLETE_FILENAME
MyFirstCommand ()
MySecondCommand ()
When one loads this into GDB and tries to complete filenames for both
myfirstcommand and mysecondcommand, she gets:
(gdb) myfirstcommand /hom<TAB>
(gdb) myfirstcommand /home/
^
...
(gdb) mysecondcommand /hom<TAB>
(gdb) mysecondcommand /home
^
(The "^" marks the final position of the cursor after the TAB).
So we see that myfirstcommand honors the COMPLETE_FILENAME class (as
specified in the command creation), but mysecondcommand does not. After
some investigation, I found that the problem lies with the set of word
break characters that is used for each case. The set should be the same
for both commands, but it is not.
During the process of deciding which type of completion should be used,
the code in gdb/completer.c:complete_line_internal analyses the command
that requested the completion and tries to determine the type of
completion wanted by checking which completion function will be called
(e.g., filename_completer for filenames, location_completer for
locations, etc.).
This all works fine for myfirstcommand, because immediately after the
command registration the Python backend already sets its completion
function to filename_completer (which then causes the
complete_line_internal function to choose the right set of word break
chars). However, for mysecondcommand, this decision is postponed to
when the completer function is evaluated, and the Python backend uses an
internal completer (called cmdpy_completer). complete_line_internal
doesn't know about this internal completer, and can't choose the right
set of word break chars in time, which then leads to a bad decision when
completing the "/hom" word.
So, after a few attempts, I decided to create another callback in
"struct cmd_list_element" that will be responsible for handling the case
when there is an unknown completer function for complete_line_internal
to work with. So far, only the Python backend uses this callback, and
only when the user provides a completer method instead of registering
the command directly with a completer class. I think this is the best
option because it not very intrusive (all the other commands will still
work normally), but especially because the whole completion code is so
messy that it would be hard to fix this without having to redesign
things.
I have regtested this on Fedora 18 x86_64, without regressions. I also
included a testcase.
gdb/ChangeLog:
2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* cli/cli-decode.c (set_cmd_completer_handle_brkchars): New
function.
(add_cmd): Set "completer_handle_brkchars" to NULL.
* cli/cli-decode.h (struct cmd_list_element)
<completer_handle_brkchars>: New field.
* command.h (completer_ftype_void): New typedef.
(set_cmd_completer_handle_brkchars): New prototype.
* completer.c (set_gdb_completion_word_break_characters): New
function.
(complete_line_internal): Call "completer_handle_brkchars"
callback from command.
* completer.h: Include "command.h".
(set_gdb_completion_word_break_characters): New prototype.
* python/py-cmd.c (cmdpy_completer_helper): New function.
(cmdpy_completer_handle_brkchars): New function.
(cmdpy_completer): Adjust to use cmdpy_completer_helper.
(cmdpy_init): Set completer_handle_brkchars to
cmdpy_completer_handle_brkchars.
gdb/testsuite/ChangeLog:
2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* gdb.python/py-completion.exp: New file.
* gdb.python/py-completion.py: Likewise.
2014-09-03 20:30:28 +00:00
|
|
|
|
{
|
|
|
|
|
cmdpy_object *obj = (cmdpy_object *) get_cmd_context (command);
|
|
|
|
|
PyObject *textobj, *wordobj;
|
Fix Python completion when using the "complete" command
This patch is related to PR python/16699, and is an improvement over the
patch posted here:
<https://sourceware.org/ml/gdb-patches/2014-03/msg00301.html>
Keith noticed that, when using the "complete" command on GDB to complete
a Python command, some strange things could happen. In order to
understand what can go wrong, I need to explain how the Python
completion mechanism works.
When the user requests a completion of a Python command by using TAB,
GDB will first try to determine the right set of "brkchars" that will be
used when doing the completion. This is done by actually calling the
"complete" method of the Python class. Then, when we already know the
"brkchars" that will be used, we call the "complete" method again, for
the same values.
If you read the thread mentioned above, you will see that one of the
design decisions was to make the "cmdpy_completer_helper" (which is the
function the does the actual calling of the "complete" method) cache the
first result of the completion, since this result will be used in the
second call, to do the actual completion.
The problem is that the "complete" command does not process the
brkchars, and the current Python completion mechanism (improved by the
patch mentioned above) relies on GDB trying to determine the brkchars,
and then doing the completion itself. Therefore, when we use the
"complete" command instead of doing a TAB-completion on GDB, there is a
scenario where we can use the invalid cache of a previous Python command
that was completed before. For example:
(gdb) A <TAB>
(gdb) complete B
B value1
B value10
B value2
B value3
B value4
B value5
B value6
B value7
B value8
B value9
(gdb) B <TAB>
comp1 comp2 comp4 comp6 comp8
comp10 comp3 comp5 comp7 comp9
Here, we see that "complete B " gave a different result than "B <TAB>".
The reason for that is because "A <TAB>" was called before, and its
completion results were "value*", so when GDB tried to "complete B " it
wrongly answered with the results for A. The problem here is using a
wrong cache (A's cache) for completing B.
We tried to come up with a solution that would preserve the caching
mechanism, but it wasn't really possible. So I decided to completely
remove the cache, and doing the method calling twice for every
completion. This is not optimal, but I do not think it will impact
users noticeably.
It is worth mentioning another small issue that I found. The code was
doing:
wordobj = PyUnicode_Decode (word, sizeof (word), host_charset (), NULL);
which is totally wrong, because using "sizeof" here will lead to always
the same result. So I changed this to use "strlen". The testcase also
catches this problem.
Keith kindly expanded the existing testcase to cover the problem
described above, and everything is passing.
gdb/ChangeLog:
2015-04-08 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* python/py-cmd.c (cmdpy_completer_helper): Adjust function to not
use a caching mechanism. Adjust comments and code to reflect
that. Replace 'sizeof' by 'strlen' when fetching 'wordobj'.
(cmdpy_completer_handle_brkchars): Adjust call to
cmdpy_completer_helper. Call Py_XDECREF for 'resultobj'.
(cmdpy_completer): Likewise.
gdb/testsuite/ChangeLog:
2015-04-08 Keith Seitz <keiths@redhat.com>
PR python/16699
* gdb.python/py-completion.exp: New tests for completion.
* gdb.python/py-completion.py (CompleteLimit1): New class.
(CompleteLimit2): Likewise.
(CompleteLimit3): Likewise.
(CompleteLimit4): Likewise.
(CompleteLimit5): Likewise.
(CompleteLimit6): Likewise.
(CompleteLimit7): Likewise.
2015-04-08 22:27:10 +00:00
|
|
|
|
PyObject *resultobj;
|
PR python/16699: GDB Python command completion with overriden complete vs. completer class
This PR came from a Red Hat bug that was filed recently. I checked and
it still exists on HEAD, so here's a proposed fix. Although this is
marked as a Python backend bug, this is really about the completion
mechanism used by GDB. Since this code reminds me of my first attempt
to make a good noodle, it took me quite some time to fix it in a
non-intrusive way.
The problem is triggered when one registers a completion method inside a
class in a Python script, rather than registering the command using a
completer class directly. For example, consider the following script:
class MyFirstCommand(gdb.Command):
def __init__(self):
gdb.Command.__init__(self,'myfirstcommand',gdb.COMMAND_USER,gdb.COMPLETE_FILENAME)
def invoke(self,argument,from_tty):
raise gdb.GdbError('not implemented')
class MySecondCommand(gdb.Command):
def __init__(self):
gdb.Command.__init__(self,'mysecondcommand',gdb.COMMAND_USER)
def invoke(self,argument,from_tty):
raise gdb.GdbError('not implemented')
def complete(self,text,word):
return gdb.COMPLETE_FILENAME
MyFirstCommand ()
MySecondCommand ()
When one loads this into GDB and tries to complete filenames for both
myfirstcommand and mysecondcommand, she gets:
(gdb) myfirstcommand /hom<TAB>
(gdb) myfirstcommand /home/
^
...
(gdb) mysecondcommand /hom<TAB>
(gdb) mysecondcommand /home
^
(The "^" marks the final position of the cursor after the TAB).
So we see that myfirstcommand honors the COMPLETE_FILENAME class (as
specified in the command creation), but mysecondcommand does not. After
some investigation, I found that the problem lies with the set of word
break characters that is used for each case. The set should be the same
for both commands, but it is not.
During the process of deciding which type of completion should be used,
the code in gdb/completer.c:complete_line_internal analyses the command
that requested the completion and tries to determine the type of
completion wanted by checking which completion function will be called
(e.g., filename_completer for filenames, location_completer for
locations, etc.).
This all works fine for myfirstcommand, because immediately after the
command registration the Python backend already sets its completion
function to filename_completer (which then causes the
complete_line_internal function to choose the right set of word break
chars). However, for mysecondcommand, this decision is postponed to
when the completer function is evaluated, and the Python backend uses an
internal completer (called cmdpy_completer). complete_line_internal
doesn't know about this internal completer, and can't choose the right
set of word break chars in time, which then leads to a bad decision when
completing the "/hom" word.
So, after a few attempts, I decided to create another callback in
"struct cmd_list_element" that will be responsible for handling the case
when there is an unknown completer function for complete_line_internal
to work with. So far, only the Python backend uses this callback, and
only when the user provides a completer method instead of registering
the command directly with a completer class. I think this is the best
option because it not very intrusive (all the other commands will still
work normally), but especially because the whole completion code is so
messy that it would be hard to fix this without having to redesign
things.
I have regtested this on Fedora 18 x86_64, without regressions. I also
included a testcase.
gdb/ChangeLog:
2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* cli/cli-decode.c (set_cmd_completer_handle_brkchars): New
function.
(add_cmd): Set "completer_handle_brkchars" to NULL.
* cli/cli-decode.h (struct cmd_list_element)
<completer_handle_brkchars>: New field.
* command.h (completer_ftype_void): New typedef.
(set_cmd_completer_handle_brkchars): New prototype.
* completer.c (set_gdb_completion_word_break_characters): New
function.
(complete_line_internal): Call "completer_handle_brkchars"
callback from command.
* completer.h: Include "command.h".
(set_gdb_completion_word_break_characters): New prototype.
* python/py-cmd.c (cmdpy_completer_helper): New function.
(cmdpy_completer_handle_brkchars): New function.
(cmdpy_completer): Adjust to use cmdpy_completer_helper.
(cmdpy_init): Set completer_handle_brkchars to
cmdpy_completer_handle_brkchars.
gdb/testsuite/ChangeLog:
2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* gdb.python/py-completion.exp: New file.
* gdb.python/py-completion.py: Likewise.
2014-09-03 20:30:28 +00:00
|
|
|
|
|
Fix Python completion when using the "complete" command
This patch is related to PR python/16699, and is an improvement over the
patch posted here:
<https://sourceware.org/ml/gdb-patches/2014-03/msg00301.html>
Keith noticed that, when using the "complete" command on GDB to complete
a Python command, some strange things could happen. In order to
understand what can go wrong, I need to explain how the Python
completion mechanism works.
When the user requests a completion of a Python command by using TAB,
GDB will first try to determine the right set of "brkchars" that will be
used when doing the completion. This is done by actually calling the
"complete" method of the Python class. Then, when we already know the
"brkchars" that will be used, we call the "complete" method again, for
the same values.
If you read the thread mentioned above, you will see that one of the
design decisions was to make the "cmdpy_completer_helper" (which is the
function the does the actual calling of the "complete" method) cache the
first result of the completion, since this result will be used in the
second call, to do the actual completion.
The problem is that the "complete" command does not process the
brkchars, and the current Python completion mechanism (improved by the
patch mentioned above) relies on GDB trying to determine the brkchars,
and then doing the completion itself. Therefore, when we use the
"complete" command instead of doing a TAB-completion on GDB, there is a
scenario where we can use the invalid cache of a previous Python command
that was completed before. For example:
(gdb) A <TAB>
(gdb) complete B
B value1
B value10
B value2
B value3
B value4
B value5
B value6
B value7
B value8
B value9
(gdb) B <TAB>
comp1 comp2 comp4 comp6 comp8
comp10 comp3 comp5 comp7 comp9
Here, we see that "complete B " gave a different result than "B <TAB>".
The reason for that is because "A <TAB>" was called before, and its
completion results were "value*", so when GDB tried to "complete B " it
wrongly answered with the results for A. The problem here is using a
wrong cache (A's cache) for completing B.
We tried to come up with a solution that would preserve the caching
mechanism, but it wasn't really possible. So I decided to completely
remove the cache, and doing the method calling twice for every
completion. This is not optimal, but I do not think it will impact
users noticeably.
It is worth mentioning another small issue that I found. The code was
doing:
wordobj = PyUnicode_Decode (word, sizeof (word), host_charset (), NULL);
which is totally wrong, because using "sizeof" here will lead to always
the same result. So I changed this to use "strlen". The testcase also
catches this problem.
Keith kindly expanded the existing testcase to cover the problem
described above, and everything is passing.
gdb/ChangeLog:
2015-04-08 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* python/py-cmd.c (cmdpy_completer_helper): Adjust function to not
use a caching mechanism. Adjust comments and code to reflect
that. Replace 'sizeof' by 'strlen' when fetching 'wordobj'.
(cmdpy_completer_handle_brkchars): Adjust call to
cmdpy_completer_helper. Call Py_XDECREF for 'resultobj'.
(cmdpy_completer): Likewise.
gdb/testsuite/ChangeLog:
2015-04-08 Keith Seitz <keiths@redhat.com>
PR python/16699
* gdb.python/py-completion.exp: New tests for completion.
* gdb.python/py-completion.py (CompleteLimit1): New class.
(CompleteLimit2): Likewise.
(CompleteLimit3): Likewise.
(CompleteLimit4): Likewise.
(CompleteLimit5): Likewise.
(CompleteLimit6): Likewise.
(CompleteLimit7): Likewise.
2015-04-08 22:27:10 +00:00
|
|
|
|
if (obj == NULL)
|
|
|
|
|
error (_("Invalid invocation of Python command object."));
|
|
|
|
|
if (!PyObject_HasAttr ((PyObject *) obj, complete_cst))
|
PR python/16699: GDB Python command completion with overriden complete vs. completer class
This PR came from a Red Hat bug that was filed recently. I checked and
it still exists on HEAD, so here's a proposed fix. Although this is
marked as a Python backend bug, this is really about the completion
mechanism used by GDB. Since this code reminds me of my first attempt
to make a good noodle, it took me quite some time to fix it in a
non-intrusive way.
The problem is triggered when one registers a completion method inside a
class in a Python script, rather than registering the command using a
completer class directly. For example, consider the following script:
class MyFirstCommand(gdb.Command):
def __init__(self):
gdb.Command.__init__(self,'myfirstcommand',gdb.COMMAND_USER,gdb.COMPLETE_FILENAME)
def invoke(self,argument,from_tty):
raise gdb.GdbError('not implemented')
class MySecondCommand(gdb.Command):
def __init__(self):
gdb.Command.__init__(self,'mysecondcommand',gdb.COMMAND_USER)
def invoke(self,argument,from_tty):
raise gdb.GdbError('not implemented')
def complete(self,text,word):
return gdb.COMPLETE_FILENAME
MyFirstCommand ()
MySecondCommand ()
When one loads this into GDB and tries to complete filenames for both
myfirstcommand and mysecondcommand, she gets:
(gdb) myfirstcommand /hom<TAB>
(gdb) myfirstcommand /home/
^
...
(gdb) mysecondcommand /hom<TAB>
(gdb) mysecondcommand /home
^
(The "^" marks the final position of the cursor after the TAB).
So we see that myfirstcommand honors the COMPLETE_FILENAME class (as
specified in the command creation), but mysecondcommand does not. After
some investigation, I found that the problem lies with the set of word
break characters that is used for each case. The set should be the same
for both commands, but it is not.
During the process of deciding which type of completion should be used,
the code in gdb/completer.c:complete_line_internal analyses the command
that requested the completion and tries to determine the type of
completion wanted by checking which completion function will be called
(e.g., filename_completer for filenames, location_completer for
locations, etc.).
This all works fine for myfirstcommand, because immediately after the
command registration the Python backend already sets its completion
function to filename_completer (which then causes the
complete_line_internal function to choose the right set of word break
chars). However, for mysecondcommand, this decision is postponed to
when the completer function is evaluated, and the Python backend uses an
internal completer (called cmdpy_completer). complete_line_internal
doesn't know about this internal completer, and can't choose the right
set of word break chars in time, which then leads to a bad decision when
completing the "/hom" word.
So, after a few attempts, I decided to create another callback in
"struct cmd_list_element" that will be responsible for handling the case
when there is an unknown completer function for complete_line_internal
to work with. So far, only the Python backend uses this callback, and
only when the user provides a completer method instead of registering
the command directly with a completer class. I think this is the best
option because it not very intrusive (all the other commands will still
work normally), but especially because the whole completion code is so
messy that it would be hard to fix this without having to redesign
things.
I have regtested this on Fedora 18 x86_64, without regressions. I also
included a testcase.
gdb/ChangeLog:
2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* cli/cli-decode.c (set_cmd_completer_handle_brkchars): New
function.
(add_cmd): Set "completer_handle_brkchars" to NULL.
* cli/cli-decode.h (struct cmd_list_element)
<completer_handle_brkchars>: New field.
* command.h (completer_ftype_void): New typedef.
(set_cmd_completer_handle_brkchars): New prototype.
* completer.c (set_gdb_completion_word_break_characters): New
function.
(complete_line_internal): Call "completer_handle_brkchars"
callback from command.
* completer.h: Include "command.h".
(set_gdb_completion_word_break_characters): New prototype.
* python/py-cmd.c (cmdpy_completer_helper): New function.
(cmdpy_completer_handle_brkchars): New function.
(cmdpy_completer): Adjust to use cmdpy_completer_helper.
(cmdpy_init): Set completer_handle_brkchars to
cmdpy_completer_handle_brkchars.
gdb/testsuite/ChangeLog:
2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* gdb.python/py-completion.exp: New file.
* gdb.python/py-completion.py: Likewise.
2014-09-03 20:30:28 +00:00
|
|
|
|
{
|
Fix Python completion when using the "complete" command
This patch is related to PR python/16699, and is an improvement over the
patch posted here:
<https://sourceware.org/ml/gdb-patches/2014-03/msg00301.html>
Keith noticed that, when using the "complete" command on GDB to complete
a Python command, some strange things could happen. In order to
understand what can go wrong, I need to explain how the Python
completion mechanism works.
When the user requests a completion of a Python command by using TAB,
GDB will first try to determine the right set of "brkchars" that will be
used when doing the completion. This is done by actually calling the
"complete" method of the Python class. Then, when we already know the
"brkchars" that will be used, we call the "complete" method again, for
the same values.
If you read the thread mentioned above, you will see that one of the
design decisions was to make the "cmdpy_completer_helper" (which is the
function the does the actual calling of the "complete" method) cache the
first result of the completion, since this result will be used in the
second call, to do the actual completion.
The problem is that the "complete" command does not process the
brkchars, and the current Python completion mechanism (improved by the
patch mentioned above) relies on GDB trying to determine the brkchars,
and then doing the completion itself. Therefore, when we use the
"complete" command instead of doing a TAB-completion on GDB, there is a
scenario where we can use the invalid cache of a previous Python command
that was completed before. For example:
(gdb) A <TAB>
(gdb) complete B
B value1
B value10
B value2
B value3
B value4
B value5
B value6
B value7
B value8
B value9
(gdb) B <TAB>
comp1 comp2 comp4 comp6 comp8
comp10 comp3 comp5 comp7 comp9
Here, we see that "complete B " gave a different result than "B <TAB>".
The reason for that is because "A <TAB>" was called before, and its
completion results were "value*", so when GDB tried to "complete B " it
wrongly answered with the results for A. The problem here is using a
wrong cache (A's cache) for completing B.
We tried to come up with a solution that would preserve the caching
mechanism, but it wasn't really possible. So I decided to completely
remove the cache, and doing the method calling twice for every
completion. This is not optimal, but I do not think it will impact
users noticeably.
It is worth mentioning another small issue that I found. The code was
doing:
wordobj = PyUnicode_Decode (word, sizeof (word), host_charset (), NULL);
which is totally wrong, because using "sizeof" here will lead to always
the same result. So I changed this to use "strlen". The testcase also
catches this problem.
Keith kindly expanded the existing testcase to cover the problem
described above, and everything is passing.
gdb/ChangeLog:
2015-04-08 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* python/py-cmd.c (cmdpy_completer_helper): Adjust function to not
use a caching mechanism. Adjust comments and code to reflect
that. Replace 'sizeof' by 'strlen' when fetching 'wordobj'.
(cmdpy_completer_handle_brkchars): Adjust call to
cmdpy_completer_helper. Call Py_XDECREF for 'resultobj'.
(cmdpy_completer): Likewise.
gdb/testsuite/ChangeLog:
2015-04-08 Keith Seitz <keiths@redhat.com>
PR python/16699
* gdb.python/py-completion.exp: New tests for completion.
* gdb.python/py-completion.py (CompleteLimit1): New class.
(CompleteLimit2): Likewise.
(CompleteLimit3): Likewise.
(CompleteLimit4): Likewise.
(CompleteLimit5): Likewise.
(CompleteLimit6): Likewise.
(CompleteLimit7): Likewise.
2015-04-08 22:27:10 +00:00
|
|
|
|
/* If there is no complete method, don't error. */
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
PR python/16699: GDB Python command completion with overriden complete vs. completer class
This PR came from a Red Hat bug that was filed recently. I checked and
it still exists on HEAD, so here's a proposed fix. Although this is
marked as a Python backend bug, this is really about the completion
mechanism used by GDB. Since this code reminds me of my first attempt
to make a good noodle, it took me quite some time to fix it in a
non-intrusive way.
The problem is triggered when one registers a completion method inside a
class in a Python script, rather than registering the command using a
completer class directly. For example, consider the following script:
class MyFirstCommand(gdb.Command):
def __init__(self):
gdb.Command.__init__(self,'myfirstcommand',gdb.COMMAND_USER,gdb.COMPLETE_FILENAME)
def invoke(self,argument,from_tty):
raise gdb.GdbError('not implemented')
class MySecondCommand(gdb.Command):
def __init__(self):
gdb.Command.__init__(self,'mysecondcommand',gdb.COMMAND_USER)
def invoke(self,argument,from_tty):
raise gdb.GdbError('not implemented')
def complete(self,text,word):
return gdb.COMPLETE_FILENAME
MyFirstCommand ()
MySecondCommand ()
When one loads this into GDB and tries to complete filenames for both
myfirstcommand and mysecondcommand, she gets:
(gdb) myfirstcommand /hom<TAB>
(gdb) myfirstcommand /home/
^
...
(gdb) mysecondcommand /hom<TAB>
(gdb) mysecondcommand /home
^
(The "^" marks the final position of the cursor after the TAB).
So we see that myfirstcommand honors the COMPLETE_FILENAME class (as
specified in the command creation), but mysecondcommand does not. After
some investigation, I found that the problem lies with the set of word
break characters that is used for each case. The set should be the same
for both commands, but it is not.
During the process of deciding which type of completion should be used,
the code in gdb/completer.c:complete_line_internal analyses the command
that requested the completion and tries to determine the type of
completion wanted by checking which completion function will be called
(e.g., filename_completer for filenames, location_completer for
locations, etc.).
This all works fine for myfirstcommand, because immediately after the
command registration the Python backend already sets its completion
function to filename_completer (which then causes the
complete_line_internal function to choose the right set of word break
chars). However, for mysecondcommand, this decision is postponed to
when the completer function is evaluated, and the Python backend uses an
internal completer (called cmdpy_completer). complete_line_internal
doesn't know about this internal completer, and can't choose the right
set of word break chars in time, which then leads to a bad decision when
completing the "/hom" word.
So, after a few attempts, I decided to create another callback in
"struct cmd_list_element" that will be responsible for handling the case
when there is an unknown completer function for complete_line_internal
to work with. So far, only the Python backend uses this callback, and
only when the user provides a completer method instead of registering
the command directly with a completer class. I think this is the best
option because it not very intrusive (all the other commands will still
work normally), but especially because the whole completion code is so
messy that it would be hard to fix this without having to redesign
things.
I have regtested this on Fedora 18 x86_64, without regressions. I also
included a testcase.
gdb/ChangeLog:
2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* cli/cli-decode.c (set_cmd_completer_handle_brkchars): New
function.
(add_cmd): Set "completer_handle_brkchars" to NULL.
* cli/cli-decode.h (struct cmd_list_element)
<completer_handle_brkchars>: New field.
* command.h (completer_ftype_void): New typedef.
(set_cmd_completer_handle_brkchars): New prototype.
* completer.c (set_gdb_completion_word_break_characters): New
function.
(complete_line_internal): Call "completer_handle_brkchars"
callback from command.
* completer.h: Include "command.h".
(set_gdb_completion_word_break_characters): New prototype.
* python/py-cmd.c (cmdpy_completer_helper): New function.
(cmdpy_completer_handle_brkchars): New function.
(cmdpy_completer): Adjust to use cmdpy_completer_helper.
(cmdpy_init): Set completer_handle_brkchars to
cmdpy_completer_handle_brkchars.
gdb/testsuite/ChangeLog:
2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* gdb.python/py-completion.exp: New file.
* gdb.python/py-completion.py: Likewise.
2014-09-03 20:30:28 +00:00
|
|
|
|
|
Fix Python completion when using the "complete" command
This patch is related to PR python/16699, and is an improvement over the
patch posted here:
<https://sourceware.org/ml/gdb-patches/2014-03/msg00301.html>
Keith noticed that, when using the "complete" command on GDB to complete
a Python command, some strange things could happen. In order to
understand what can go wrong, I need to explain how the Python
completion mechanism works.
When the user requests a completion of a Python command by using TAB,
GDB will first try to determine the right set of "brkchars" that will be
used when doing the completion. This is done by actually calling the
"complete" method of the Python class. Then, when we already know the
"brkchars" that will be used, we call the "complete" method again, for
the same values.
If you read the thread mentioned above, you will see that one of the
design decisions was to make the "cmdpy_completer_helper" (which is the
function the does the actual calling of the "complete" method) cache the
first result of the completion, since this result will be used in the
second call, to do the actual completion.
The problem is that the "complete" command does not process the
brkchars, and the current Python completion mechanism (improved by the
patch mentioned above) relies on GDB trying to determine the brkchars,
and then doing the completion itself. Therefore, when we use the
"complete" command instead of doing a TAB-completion on GDB, there is a
scenario where we can use the invalid cache of a previous Python command
that was completed before. For example:
(gdb) A <TAB>
(gdb) complete B
B value1
B value10
B value2
B value3
B value4
B value5
B value6
B value7
B value8
B value9
(gdb) B <TAB>
comp1 comp2 comp4 comp6 comp8
comp10 comp3 comp5 comp7 comp9
Here, we see that "complete B " gave a different result than "B <TAB>".
The reason for that is because "A <TAB>" was called before, and its
completion results were "value*", so when GDB tried to "complete B " it
wrongly answered with the results for A. The problem here is using a
wrong cache (A's cache) for completing B.
We tried to come up with a solution that would preserve the caching
mechanism, but it wasn't really possible. So I decided to completely
remove the cache, and doing the method calling twice for every
completion. This is not optimal, but I do not think it will impact
users noticeably.
It is worth mentioning another small issue that I found. The code was
doing:
wordobj = PyUnicode_Decode (word, sizeof (word), host_charset (), NULL);
which is totally wrong, because using "sizeof" here will lead to always
the same result. So I changed this to use "strlen". The testcase also
catches this problem.
Keith kindly expanded the existing testcase to cover the problem
described above, and everything is passing.
gdb/ChangeLog:
2015-04-08 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* python/py-cmd.c (cmdpy_completer_helper): Adjust function to not
use a caching mechanism. Adjust comments and code to reflect
that. Replace 'sizeof' by 'strlen' when fetching 'wordobj'.
(cmdpy_completer_handle_brkchars): Adjust call to
cmdpy_completer_helper. Call Py_XDECREF for 'resultobj'.
(cmdpy_completer): Likewise.
gdb/testsuite/ChangeLog:
2015-04-08 Keith Seitz <keiths@redhat.com>
PR python/16699
* gdb.python/py-completion.exp: New tests for completion.
* gdb.python/py-completion.py (CompleteLimit1): New class.
(CompleteLimit2): Likewise.
(CompleteLimit3): Likewise.
(CompleteLimit4): Likewise.
(CompleteLimit5): Likewise.
(CompleteLimit6): Likewise.
(CompleteLimit7): Likewise.
2015-04-08 22:27:10 +00:00
|
|
|
|
textobj = PyUnicode_Decode (text, strlen (text), host_charset (), NULL);
|
|
|
|
|
if (textobj == NULL)
|
|
|
|
|
error (_("Could not convert argument to Python string."));
|
|
|
|
|
wordobj = PyUnicode_Decode (word, strlen (word), host_charset (), NULL);
|
|
|
|
|
if (wordobj == NULL)
|
|
|
|
|
{
|
PR python/16699: GDB Python command completion with overriden complete vs. completer class
This PR came from a Red Hat bug that was filed recently. I checked and
it still exists on HEAD, so here's a proposed fix. Although this is
marked as a Python backend bug, this is really about the completion
mechanism used by GDB. Since this code reminds me of my first attempt
to make a good noodle, it took me quite some time to fix it in a
non-intrusive way.
The problem is triggered when one registers a completion method inside a
class in a Python script, rather than registering the command using a
completer class directly. For example, consider the following script:
class MyFirstCommand(gdb.Command):
def __init__(self):
gdb.Command.__init__(self,'myfirstcommand',gdb.COMMAND_USER,gdb.COMPLETE_FILENAME)
def invoke(self,argument,from_tty):
raise gdb.GdbError('not implemented')
class MySecondCommand(gdb.Command):
def __init__(self):
gdb.Command.__init__(self,'mysecondcommand',gdb.COMMAND_USER)
def invoke(self,argument,from_tty):
raise gdb.GdbError('not implemented')
def complete(self,text,word):
return gdb.COMPLETE_FILENAME
MyFirstCommand ()
MySecondCommand ()
When one loads this into GDB and tries to complete filenames for both
myfirstcommand and mysecondcommand, she gets:
(gdb) myfirstcommand /hom<TAB>
(gdb) myfirstcommand /home/
^
...
(gdb) mysecondcommand /hom<TAB>
(gdb) mysecondcommand /home
^
(The "^" marks the final position of the cursor after the TAB).
So we see that myfirstcommand honors the COMPLETE_FILENAME class (as
specified in the command creation), but mysecondcommand does not. After
some investigation, I found that the problem lies with the set of word
break characters that is used for each case. The set should be the same
for both commands, but it is not.
During the process of deciding which type of completion should be used,
the code in gdb/completer.c:complete_line_internal analyses the command
that requested the completion and tries to determine the type of
completion wanted by checking which completion function will be called
(e.g., filename_completer for filenames, location_completer for
locations, etc.).
This all works fine for myfirstcommand, because immediately after the
command registration the Python backend already sets its completion
function to filename_completer (which then causes the
complete_line_internal function to choose the right set of word break
chars). However, for mysecondcommand, this decision is postponed to
when the completer function is evaluated, and the Python backend uses an
internal completer (called cmdpy_completer). complete_line_internal
doesn't know about this internal completer, and can't choose the right
set of word break chars in time, which then leads to a bad decision when
completing the "/hom" word.
So, after a few attempts, I decided to create another callback in
"struct cmd_list_element" that will be responsible for handling the case
when there is an unknown completer function for complete_line_internal
to work with. So far, only the Python backend uses this callback, and
only when the user provides a completer method instead of registering
the command directly with a completer class. I think this is the best
option because it not very intrusive (all the other commands will still
work normally), but especially because the whole completion code is so
messy that it would be hard to fix this without having to redesign
things.
I have regtested this on Fedora 18 x86_64, without regressions. I also
included a testcase.
gdb/ChangeLog:
2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* cli/cli-decode.c (set_cmd_completer_handle_brkchars): New
function.
(add_cmd): Set "completer_handle_brkchars" to NULL.
* cli/cli-decode.h (struct cmd_list_element)
<completer_handle_brkchars>: New field.
* command.h (completer_ftype_void): New typedef.
(set_cmd_completer_handle_brkchars): New prototype.
* completer.c (set_gdb_completion_word_break_characters): New
function.
(complete_line_internal): Call "completer_handle_brkchars"
callback from command.
* completer.h: Include "command.h".
(set_gdb_completion_word_break_characters): New prototype.
* python/py-cmd.c (cmdpy_completer_helper): New function.
(cmdpy_completer_handle_brkchars): New function.
(cmdpy_completer): Adjust to use cmdpy_completer_helper.
(cmdpy_init): Set completer_handle_brkchars to
cmdpy_completer_handle_brkchars.
gdb/testsuite/ChangeLog:
2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* gdb.python/py-completion.exp: New file.
* gdb.python/py-completion.py: Likewise.
2014-09-03 20:30:28 +00:00
|
|
|
|
Py_DECREF (textobj);
|
Fix Python completion when using the "complete" command
This patch is related to PR python/16699, and is an improvement over the
patch posted here:
<https://sourceware.org/ml/gdb-patches/2014-03/msg00301.html>
Keith noticed that, when using the "complete" command on GDB to complete
a Python command, some strange things could happen. In order to
understand what can go wrong, I need to explain how the Python
completion mechanism works.
When the user requests a completion of a Python command by using TAB,
GDB will first try to determine the right set of "brkchars" that will be
used when doing the completion. This is done by actually calling the
"complete" method of the Python class. Then, when we already know the
"brkchars" that will be used, we call the "complete" method again, for
the same values.
If you read the thread mentioned above, you will see that one of the
design decisions was to make the "cmdpy_completer_helper" (which is the
function the does the actual calling of the "complete" method) cache the
first result of the completion, since this result will be used in the
second call, to do the actual completion.
The problem is that the "complete" command does not process the
brkchars, and the current Python completion mechanism (improved by the
patch mentioned above) relies on GDB trying to determine the brkchars,
and then doing the completion itself. Therefore, when we use the
"complete" command instead of doing a TAB-completion on GDB, there is a
scenario where we can use the invalid cache of a previous Python command
that was completed before. For example:
(gdb) A <TAB>
(gdb) complete B
B value1
B value10
B value2
B value3
B value4
B value5
B value6
B value7
B value8
B value9
(gdb) B <TAB>
comp1 comp2 comp4 comp6 comp8
comp10 comp3 comp5 comp7 comp9
Here, we see that "complete B " gave a different result than "B <TAB>".
The reason for that is because "A <TAB>" was called before, and its
completion results were "value*", so when GDB tried to "complete B " it
wrongly answered with the results for A. The problem here is using a
wrong cache (A's cache) for completing B.
We tried to come up with a solution that would preserve the caching
mechanism, but it wasn't really possible. So I decided to completely
remove the cache, and doing the method calling twice for every
completion. This is not optimal, but I do not think it will impact
users noticeably.
It is worth mentioning another small issue that I found. The code was
doing:
wordobj = PyUnicode_Decode (word, sizeof (word), host_charset (), NULL);
which is totally wrong, because using "sizeof" here will lead to always
the same result. So I changed this to use "strlen". The testcase also
catches this problem.
Keith kindly expanded the existing testcase to cover the problem
described above, and everything is passing.
gdb/ChangeLog:
2015-04-08 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* python/py-cmd.c (cmdpy_completer_helper): Adjust function to not
use a caching mechanism. Adjust comments and code to reflect
that. Replace 'sizeof' by 'strlen' when fetching 'wordobj'.
(cmdpy_completer_handle_brkchars): Adjust call to
cmdpy_completer_helper. Call Py_XDECREF for 'resultobj'.
(cmdpy_completer): Likewise.
gdb/testsuite/ChangeLog:
2015-04-08 Keith Seitz <keiths@redhat.com>
PR python/16699
* gdb.python/py-completion.exp: New tests for completion.
* gdb.python/py-completion.py (CompleteLimit1): New class.
(CompleteLimit2): Likewise.
(CompleteLimit3): Likewise.
(CompleteLimit4): Likewise.
(CompleteLimit5): Likewise.
(CompleteLimit6): Likewise.
(CompleteLimit7): Likewise.
2015-04-08 22:27:10 +00:00
|
|
|
|
error (_("Could not convert argument to Python string."));
|
|
|
|
|
}
|
PR python/16699: GDB Python command completion with overriden complete vs. completer class
This PR came from a Red Hat bug that was filed recently. I checked and
it still exists on HEAD, so here's a proposed fix. Although this is
marked as a Python backend bug, this is really about the completion
mechanism used by GDB. Since this code reminds me of my first attempt
to make a good noodle, it took me quite some time to fix it in a
non-intrusive way.
The problem is triggered when one registers a completion method inside a
class in a Python script, rather than registering the command using a
completer class directly. For example, consider the following script:
class MyFirstCommand(gdb.Command):
def __init__(self):
gdb.Command.__init__(self,'myfirstcommand',gdb.COMMAND_USER,gdb.COMPLETE_FILENAME)
def invoke(self,argument,from_tty):
raise gdb.GdbError('not implemented')
class MySecondCommand(gdb.Command):
def __init__(self):
gdb.Command.__init__(self,'mysecondcommand',gdb.COMMAND_USER)
def invoke(self,argument,from_tty):
raise gdb.GdbError('not implemented')
def complete(self,text,word):
return gdb.COMPLETE_FILENAME
MyFirstCommand ()
MySecondCommand ()
When one loads this into GDB and tries to complete filenames for both
myfirstcommand and mysecondcommand, she gets:
(gdb) myfirstcommand /hom<TAB>
(gdb) myfirstcommand /home/
^
...
(gdb) mysecondcommand /hom<TAB>
(gdb) mysecondcommand /home
^
(The "^" marks the final position of the cursor after the TAB).
So we see that myfirstcommand honors the COMPLETE_FILENAME class (as
specified in the command creation), but mysecondcommand does not. After
some investigation, I found that the problem lies with the set of word
break characters that is used for each case. The set should be the same
for both commands, but it is not.
During the process of deciding which type of completion should be used,
the code in gdb/completer.c:complete_line_internal analyses the command
that requested the completion and tries to determine the type of
completion wanted by checking which completion function will be called
(e.g., filename_completer for filenames, location_completer for
locations, etc.).
This all works fine for myfirstcommand, because immediately after the
command registration the Python backend already sets its completion
function to filename_completer (which then causes the
complete_line_internal function to choose the right set of word break
chars). However, for mysecondcommand, this decision is postponed to
when the completer function is evaluated, and the Python backend uses an
internal completer (called cmdpy_completer). complete_line_internal
doesn't know about this internal completer, and can't choose the right
set of word break chars in time, which then leads to a bad decision when
completing the "/hom" word.
So, after a few attempts, I decided to create another callback in
"struct cmd_list_element" that will be responsible for handling the case
when there is an unknown completer function for complete_line_internal
to work with. So far, only the Python backend uses this callback, and
only when the user provides a completer method instead of registering
the command directly with a completer class. I think this is the best
option because it not very intrusive (all the other commands will still
work normally), but especially because the whole completion code is so
messy that it would be hard to fix this without having to redesign
things.
I have regtested this on Fedora 18 x86_64, without regressions. I also
included a testcase.
gdb/ChangeLog:
2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* cli/cli-decode.c (set_cmd_completer_handle_brkchars): New
function.
(add_cmd): Set "completer_handle_brkchars" to NULL.
* cli/cli-decode.h (struct cmd_list_element)
<completer_handle_brkchars>: New field.
* command.h (completer_ftype_void): New typedef.
(set_cmd_completer_handle_brkchars): New prototype.
* completer.c (set_gdb_completion_word_break_characters): New
function.
(complete_line_internal): Call "completer_handle_brkchars"
callback from command.
* completer.h: Include "command.h".
(set_gdb_completion_word_break_characters): New prototype.
* python/py-cmd.c (cmdpy_completer_helper): New function.
(cmdpy_completer_handle_brkchars): New function.
(cmdpy_completer): Adjust to use cmdpy_completer_helper.
(cmdpy_init): Set completer_handle_brkchars to
cmdpy_completer_handle_brkchars.
gdb/testsuite/ChangeLog:
2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* gdb.python/py-completion.exp: New file.
* gdb.python/py-completion.py: Likewise.
2014-09-03 20:30:28 +00:00
|
|
|
|
|
Fix Python completion when using the "complete" command
This patch is related to PR python/16699, and is an improvement over the
patch posted here:
<https://sourceware.org/ml/gdb-patches/2014-03/msg00301.html>
Keith noticed that, when using the "complete" command on GDB to complete
a Python command, some strange things could happen. In order to
understand what can go wrong, I need to explain how the Python
completion mechanism works.
When the user requests a completion of a Python command by using TAB,
GDB will first try to determine the right set of "brkchars" that will be
used when doing the completion. This is done by actually calling the
"complete" method of the Python class. Then, when we already know the
"brkchars" that will be used, we call the "complete" method again, for
the same values.
If you read the thread mentioned above, you will see that one of the
design decisions was to make the "cmdpy_completer_helper" (which is the
function the does the actual calling of the "complete" method) cache the
first result of the completion, since this result will be used in the
second call, to do the actual completion.
The problem is that the "complete" command does not process the
brkchars, and the current Python completion mechanism (improved by the
patch mentioned above) relies on GDB trying to determine the brkchars,
and then doing the completion itself. Therefore, when we use the
"complete" command instead of doing a TAB-completion on GDB, there is a
scenario where we can use the invalid cache of a previous Python command
that was completed before. For example:
(gdb) A <TAB>
(gdb) complete B
B value1
B value10
B value2
B value3
B value4
B value5
B value6
B value7
B value8
B value9
(gdb) B <TAB>
comp1 comp2 comp4 comp6 comp8
comp10 comp3 comp5 comp7 comp9
Here, we see that "complete B " gave a different result than "B <TAB>".
The reason for that is because "A <TAB>" was called before, and its
completion results were "value*", so when GDB tried to "complete B " it
wrongly answered with the results for A. The problem here is using a
wrong cache (A's cache) for completing B.
We tried to come up with a solution that would preserve the caching
mechanism, but it wasn't really possible. So I decided to completely
remove the cache, and doing the method calling twice for every
completion. This is not optimal, but I do not think it will impact
users noticeably.
It is worth mentioning another small issue that I found. The code was
doing:
wordobj = PyUnicode_Decode (word, sizeof (word), host_charset (), NULL);
which is totally wrong, because using "sizeof" here will lead to always
the same result. So I changed this to use "strlen". The testcase also
catches this problem.
Keith kindly expanded the existing testcase to cover the problem
described above, and everything is passing.
gdb/ChangeLog:
2015-04-08 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* python/py-cmd.c (cmdpy_completer_helper): Adjust function to not
use a caching mechanism. Adjust comments and code to reflect
that. Replace 'sizeof' by 'strlen' when fetching 'wordobj'.
(cmdpy_completer_handle_brkchars): Adjust call to
cmdpy_completer_helper. Call Py_XDECREF for 'resultobj'.
(cmdpy_completer): Likewise.
gdb/testsuite/ChangeLog:
2015-04-08 Keith Seitz <keiths@redhat.com>
PR python/16699
* gdb.python/py-completion.exp: New tests for completion.
* gdb.python/py-completion.py (CompleteLimit1): New class.
(CompleteLimit2): Likewise.
(CompleteLimit3): Likewise.
(CompleteLimit4): Likewise.
(CompleteLimit5): Likewise.
(CompleteLimit6): Likewise.
(CompleteLimit7): Likewise.
2015-04-08 22:27:10 +00:00
|
|
|
|
resultobj = PyObject_CallMethodObjArgs ((PyObject *) obj, complete_cst,
|
|
|
|
|
textobj, wordobj, NULL);
|
|
|
|
|
Py_DECREF (textobj);
|
|
|
|
|
Py_DECREF (wordobj);
|
|
|
|
|
if (!resultobj)
|
|
|
|
|
{
|
|
|
|
|
/* Just swallow errors here. */
|
|
|
|
|
PyErr_Clear ();
|
PR python/16699: GDB Python command completion with overriden complete vs. completer class
This PR came from a Red Hat bug that was filed recently. I checked and
it still exists on HEAD, so here's a proposed fix. Although this is
marked as a Python backend bug, this is really about the completion
mechanism used by GDB. Since this code reminds me of my first attempt
to make a good noodle, it took me quite some time to fix it in a
non-intrusive way.
The problem is triggered when one registers a completion method inside a
class in a Python script, rather than registering the command using a
completer class directly. For example, consider the following script:
class MyFirstCommand(gdb.Command):
def __init__(self):
gdb.Command.__init__(self,'myfirstcommand',gdb.COMMAND_USER,gdb.COMPLETE_FILENAME)
def invoke(self,argument,from_tty):
raise gdb.GdbError('not implemented')
class MySecondCommand(gdb.Command):
def __init__(self):
gdb.Command.__init__(self,'mysecondcommand',gdb.COMMAND_USER)
def invoke(self,argument,from_tty):
raise gdb.GdbError('not implemented')
def complete(self,text,word):
return gdb.COMPLETE_FILENAME
MyFirstCommand ()
MySecondCommand ()
When one loads this into GDB and tries to complete filenames for both
myfirstcommand and mysecondcommand, she gets:
(gdb) myfirstcommand /hom<TAB>
(gdb) myfirstcommand /home/
^
...
(gdb) mysecondcommand /hom<TAB>
(gdb) mysecondcommand /home
^
(The "^" marks the final position of the cursor after the TAB).
So we see that myfirstcommand honors the COMPLETE_FILENAME class (as
specified in the command creation), but mysecondcommand does not. After
some investigation, I found that the problem lies with the set of word
break characters that is used for each case. The set should be the same
for both commands, but it is not.
During the process of deciding which type of completion should be used,
the code in gdb/completer.c:complete_line_internal analyses the command
that requested the completion and tries to determine the type of
completion wanted by checking which completion function will be called
(e.g., filename_completer for filenames, location_completer for
locations, etc.).
This all works fine for myfirstcommand, because immediately after the
command registration the Python backend already sets its completion
function to filename_completer (which then causes the
complete_line_internal function to choose the right set of word break
chars). However, for mysecondcommand, this decision is postponed to
when the completer function is evaluated, and the Python backend uses an
internal completer (called cmdpy_completer). complete_line_internal
doesn't know about this internal completer, and can't choose the right
set of word break chars in time, which then leads to a bad decision when
completing the "/hom" word.
So, after a few attempts, I decided to create another callback in
"struct cmd_list_element" that will be responsible for handling the case
when there is an unknown completer function for complete_line_internal
to work with. So far, only the Python backend uses this callback, and
only when the user provides a completer method instead of registering
the command directly with a completer class. I think this is the best
option because it not very intrusive (all the other commands will still
work normally), but especially because the whole completion code is so
messy that it would be hard to fix this without having to redesign
things.
I have regtested this on Fedora 18 x86_64, without regressions. I also
included a testcase.
gdb/ChangeLog:
2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* cli/cli-decode.c (set_cmd_completer_handle_brkchars): New
function.
(add_cmd): Set "completer_handle_brkchars" to NULL.
* cli/cli-decode.h (struct cmd_list_element)
<completer_handle_brkchars>: New field.
* command.h (completer_ftype_void): New typedef.
(set_cmd_completer_handle_brkchars): New prototype.
* completer.c (set_gdb_completion_word_break_characters): New
function.
(complete_line_internal): Call "completer_handle_brkchars"
callback from command.
* completer.h: Include "command.h".
(set_gdb_completion_word_break_characters): New prototype.
* python/py-cmd.c (cmdpy_completer_helper): New function.
(cmdpy_completer_handle_brkchars): New function.
(cmdpy_completer): Adjust to use cmdpy_completer_helper.
(cmdpy_init): Set completer_handle_brkchars to
cmdpy_completer_handle_brkchars.
gdb/testsuite/ChangeLog:
2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* gdb.python/py-completion.exp: New file.
* gdb.python/py-completion.py: Likewise.
2014-09-03 20:30:28 +00:00
|
|
|
|
}
|
|
|
|
|
|
Fix Python completion when using the "complete" command
This patch is related to PR python/16699, and is an improvement over the
patch posted here:
<https://sourceware.org/ml/gdb-patches/2014-03/msg00301.html>
Keith noticed that, when using the "complete" command on GDB to complete
a Python command, some strange things could happen. In order to
understand what can go wrong, I need to explain how the Python
completion mechanism works.
When the user requests a completion of a Python command by using TAB,
GDB will first try to determine the right set of "brkchars" that will be
used when doing the completion. This is done by actually calling the
"complete" method of the Python class. Then, when we already know the
"brkchars" that will be used, we call the "complete" method again, for
the same values.
If you read the thread mentioned above, you will see that one of the
design decisions was to make the "cmdpy_completer_helper" (which is the
function the does the actual calling of the "complete" method) cache the
first result of the completion, since this result will be used in the
second call, to do the actual completion.
The problem is that the "complete" command does not process the
brkchars, and the current Python completion mechanism (improved by the
patch mentioned above) relies on GDB trying to determine the brkchars,
and then doing the completion itself. Therefore, when we use the
"complete" command instead of doing a TAB-completion on GDB, there is a
scenario where we can use the invalid cache of a previous Python command
that was completed before. For example:
(gdb) A <TAB>
(gdb) complete B
B value1
B value10
B value2
B value3
B value4
B value5
B value6
B value7
B value8
B value9
(gdb) B <TAB>
comp1 comp2 comp4 comp6 comp8
comp10 comp3 comp5 comp7 comp9
Here, we see that "complete B " gave a different result than "B <TAB>".
The reason for that is because "A <TAB>" was called before, and its
completion results were "value*", so when GDB tried to "complete B " it
wrongly answered with the results for A. The problem here is using a
wrong cache (A's cache) for completing B.
We tried to come up with a solution that would preserve the caching
mechanism, but it wasn't really possible. So I decided to completely
remove the cache, and doing the method calling twice for every
completion. This is not optimal, but I do not think it will impact
users noticeably.
It is worth mentioning another small issue that I found. The code was
doing:
wordobj = PyUnicode_Decode (word, sizeof (word), host_charset (), NULL);
which is totally wrong, because using "sizeof" here will lead to always
the same result. So I changed this to use "strlen". The testcase also
catches this problem.
Keith kindly expanded the existing testcase to cover the problem
described above, and everything is passing.
gdb/ChangeLog:
2015-04-08 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* python/py-cmd.c (cmdpy_completer_helper): Adjust function to not
use a caching mechanism. Adjust comments and code to reflect
that. Replace 'sizeof' by 'strlen' when fetching 'wordobj'.
(cmdpy_completer_handle_brkchars): Adjust call to
cmdpy_completer_helper. Call Py_XDECREF for 'resultobj'.
(cmdpy_completer): Likewise.
gdb/testsuite/ChangeLog:
2015-04-08 Keith Seitz <keiths@redhat.com>
PR python/16699
* gdb.python/py-completion.exp: New tests for completion.
* gdb.python/py-completion.py (CompleteLimit1): New class.
(CompleteLimit2): Likewise.
(CompleteLimit3): Likewise.
(CompleteLimit4): Likewise.
(CompleteLimit5): Likewise.
(CompleteLimit6): Likewise.
(CompleteLimit7): Likewise.
2015-04-08 22:27:10 +00:00
|
|
|
|
Py_XINCREF (resultobj);
|
|
|
|
|
|
PR python/16699: GDB Python command completion with overriden complete vs. completer class
This PR came from a Red Hat bug that was filed recently. I checked and
it still exists on HEAD, so here's a proposed fix. Although this is
marked as a Python backend bug, this is really about the completion
mechanism used by GDB. Since this code reminds me of my first attempt
to make a good noodle, it took me quite some time to fix it in a
non-intrusive way.
The problem is triggered when one registers a completion method inside a
class in a Python script, rather than registering the command using a
completer class directly. For example, consider the following script:
class MyFirstCommand(gdb.Command):
def __init__(self):
gdb.Command.__init__(self,'myfirstcommand',gdb.COMMAND_USER,gdb.COMPLETE_FILENAME)
def invoke(self,argument,from_tty):
raise gdb.GdbError('not implemented')
class MySecondCommand(gdb.Command):
def __init__(self):
gdb.Command.__init__(self,'mysecondcommand',gdb.COMMAND_USER)
def invoke(self,argument,from_tty):
raise gdb.GdbError('not implemented')
def complete(self,text,word):
return gdb.COMPLETE_FILENAME
MyFirstCommand ()
MySecondCommand ()
When one loads this into GDB and tries to complete filenames for both
myfirstcommand and mysecondcommand, she gets:
(gdb) myfirstcommand /hom<TAB>
(gdb) myfirstcommand /home/
^
...
(gdb) mysecondcommand /hom<TAB>
(gdb) mysecondcommand /home
^
(The "^" marks the final position of the cursor after the TAB).
So we see that myfirstcommand honors the COMPLETE_FILENAME class (as
specified in the command creation), but mysecondcommand does not. After
some investigation, I found that the problem lies with the set of word
break characters that is used for each case. The set should be the same
for both commands, but it is not.
During the process of deciding which type of completion should be used,
the code in gdb/completer.c:complete_line_internal analyses the command
that requested the completion and tries to determine the type of
completion wanted by checking which completion function will be called
(e.g., filename_completer for filenames, location_completer for
locations, etc.).
This all works fine for myfirstcommand, because immediately after the
command registration the Python backend already sets its completion
function to filename_completer (which then causes the
complete_line_internal function to choose the right set of word break
chars). However, for mysecondcommand, this decision is postponed to
when the completer function is evaluated, and the Python backend uses an
internal completer (called cmdpy_completer). complete_line_internal
doesn't know about this internal completer, and can't choose the right
set of word break chars in time, which then leads to a bad decision when
completing the "/hom" word.
So, after a few attempts, I decided to create another callback in
"struct cmd_list_element" that will be responsible for handling the case
when there is an unknown completer function for complete_line_internal
to work with. So far, only the Python backend uses this callback, and
only when the user provides a completer method instead of registering
the command directly with a completer class. I think this is the best
option because it not very intrusive (all the other commands will still
work normally), but especially because the whole completion code is so
messy that it would be hard to fix this without having to redesign
things.
I have regtested this on Fedora 18 x86_64, without regressions. I also
included a testcase.
gdb/ChangeLog:
2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* cli/cli-decode.c (set_cmd_completer_handle_brkchars): New
function.
(add_cmd): Set "completer_handle_brkchars" to NULL.
* cli/cli-decode.h (struct cmd_list_element)
<completer_handle_brkchars>: New field.
* command.h (completer_ftype_void): New typedef.
(set_cmd_completer_handle_brkchars): New prototype.
* completer.c (set_gdb_completion_word_break_characters): New
function.
(complete_line_internal): Call "completer_handle_brkchars"
callback from command.
* completer.h: Include "command.h".
(set_gdb_completion_word_break_characters): New prototype.
* python/py-cmd.c (cmdpy_completer_helper): New function.
(cmdpy_completer_handle_brkchars): New function.
(cmdpy_completer): Adjust to use cmdpy_completer_helper.
(cmdpy_init): Set completer_handle_brkchars to
cmdpy_completer_handle_brkchars.
gdb/testsuite/ChangeLog:
2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* gdb.python/py-completion.exp: New file.
* gdb.python/py-completion.py: Likewise.
2014-09-03 20:30:28 +00:00
|
|
|
|
return resultobj;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Python function called to determine the break characters of a
|
|
|
|
|
certain completer. We are only interested in knowing if the
|
|
|
|
|
completer registered by the user will return one of the integer
|
|
|
|
|
codes (see COMPLETER_* symbols). */
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
cmdpy_completer_handle_brkchars (struct cmd_list_element *command,
|
|
|
|
|
const char *text, const char *word)
|
|
|
|
|
{
|
|
|
|
|
PyObject *resultobj = NULL;
|
|
|
|
|
struct cleanup *cleanup;
|
|
|
|
|
|
|
|
|
|
cleanup = ensure_python_env (get_current_arch (), current_language);
|
|
|
|
|
|
|
|
|
|
/* Calling our helper to obtain the PyObject of the Python
|
|
|
|
|
function. */
|
Fix Python completion when using the "complete" command
This patch is related to PR python/16699, and is an improvement over the
patch posted here:
<https://sourceware.org/ml/gdb-patches/2014-03/msg00301.html>
Keith noticed that, when using the "complete" command on GDB to complete
a Python command, some strange things could happen. In order to
understand what can go wrong, I need to explain how the Python
completion mechanism works.
When the user requests a completion of a Python command by using TAB,
GDB will first try to determine the right set of "brkchars" that will be
used when doing the completion. This is done by actually calling the
"complete" method of the Python class. Then, when we already know the
"brkchars" that will be used, we call the "complete" method again, for
the same values.
If you read the thread mentioned above, you will see that one of the
design decisions was to make the "cmdpy_completer_helper" (which is the
function the does the actual calling of the "complete" method) cache the
first result of the completion, since this result will be used in the
second call, to do the actual completion.
The problem is that the "complete" command does not process the
brkchars, and the current Python completion mechanism (improved by the
patch mentioned above) relies on GDB trying to determine the brkchars,
and then doing the completion itself. Therefore, when we use the
"complete" command instead of doing a TAB-completion on GDB, there is a
scenario where we can use the invalid cache of a previous Python command
that was completed before. For example:
(gdb) A <TAB>
(gdb) complete B
B value1
B value10
B value2
B value3
B value4
B value5
B value6
B value7
B value8
B value9
(gdb) B <TAB>
comp1 comp2 comp4 comp6 comp8
comp10 comp3 comp5 comp7 comp9
Here, we see that "complete B " gave a different result than "B <TAB>".
The reason for that is because "A <TAB>" was called before, and its
completion results were "value*", so when GDB tried to "complete B " it
wrongly answered with the results for A. The problem here is using a
wrong cache (A's cache) for completing B.
We tried to come up with a solution that would preserve the caching
mechanism, but it wasn't really possible. So I decided to completely
remove the cache, and doing the method calling twice for every
completion. This is not optimal, but I do not think it will impact
users noticeably.
It is worth mentioning another small issue that I found. The code was
doing:
wordobj = PyUnicode_Decode (word, sizeof (word), host_charset (), NULL);
which is totally wrong, because using "sizeof" here will lead to always
the same result. So I changed this to use "strlen". The testcase also
catches this problem.
Keith kindly expanded the existing testcase to cover the problem
described above, and everything is passing.
gdb/ChangeLog:
2015-04-08 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* python/py-cmd.c (cmdpy_completer_helper): Adjust function to not
use a caching mechanism. Adjust comments and code to reflect
that. Replace 'sizeof' by 'strlen' when fetching 'wordobj'.
(cmdpy_completer_handle_brkchars): Adjust call to
cmdpy_completer_helper. Call Py_XDECREF for 'resultobj'.
(cmdpy_completer): Likewise.
gdb/testsuite/ChangeLog:
2015-04-08 Keith Seitz <keiths@redhat.com>
PR python/16699
* gdb.python/py-completion.exp: New tests for completion.
* gdb.python/py-completion.py (CompleteLimit1): New class.
(CompleteLimit2): Likewise.
(CompleteLimit3): Likewise.
(CompleteLimit4): Likewise.
(CompleteLimit5): Likewise.
(CompleteLimit6): Likewise.
(CompleteLimit7): Likewise.
2015-04-08 22:27:10 +00:00
|
|
|
|
resultobj = cmdpy_completer_helper (command, text, word);
|
PR python/16699: GDB Python command completion with overriden complete vs. completer class
This PR came from a Red Hat bug that was filed recently. I checked and
it still exists on HEAD, so here's a proposed fix. Although this is
marked as a Python backend bug, this is really about the completion
mechanism used by GDB. Since this code reminds me of my first attempt
to make a good noodle, it took me quite some time to fix it in a
non-intrusive way.
The problem is triggered when one registers a completion method inside a
class in a Python script, rather than registering the command using a
completer class directly. For example, consider the following script:
class MyFirstCommand(gdb.Command):
def __init__(self):
gdb.Command.__init__(self,'myfirstcommand',gdb.COMMAND_USER,gdb.COMPLETE_FILENAME)
def invoke(self,argument,from_tty):
raise gdb.GdbError('not implemented')
class MySecondCommand(gdb.Command):
def __init__(self):
gdb.Command.__init__(self,'mysecondcommand',gdb.COMMAND_USER)
def invoke(self,argument,from_tty):
raise gdb.GdbError('not implemented')
def complete(self,text,word):
return gdb.COMPLETE_FILENAME
MyFirstCommand ()
MySecondCommand ()
When one loads this into GDB and tries to complete filenames for both
myfirstcommand and mysecondcommand, she gets:
(gdb) myfirstcommand /hom<TAB>
(gdb) myfirstcommand /home/
^
...
(gdb) mysecondcommand /hom<TAB>
(gdb) mysecondcommand /home
^
(The "^" marks the final position of the cursor after the TAB).
So we see that myfirstcommand honors the COMPLETE_FILENAME class (as
specified in the command creation), but mysecondcommand does not. After
some investigation, I found that the problem lies with the set of word
break characters that is used for each case. The set should be the same
for both commands, but it is not.
During the process of deciding which type of completion should be used,
the code in gdb/completer.c:complete_line_internal analyses the command
that requested the completion and tries to determine the type of
completion wanted by checking which completion function will be called
(e.g., filename_completer for filenames, location_completer for
locations, etc.).
This all works fine for myfirstcommand, because immediately after the
command registration the Python backend already sets its completion
function to filename_completer (which then causes the
complete_line_internal function to choose the right set of word break
chars). However, for mysecondcommand, this decision is postponed to
when the completer function is evaluated, and the Python backend uses an
internal completer (called cmdpy_completer). complete_line_internal
doesn't know about this internal completer, and can't choose the right
set of word break chars in time, which then leads to a bad decision when
completing the "/hom" word.
So, after a few attempts, I decided to create another callback in
"struct cmd_list_element" that will be responsible for handling the case
when there is an unknown completer function for complete_line_internal
to work with. So far, only the Python backend uses this callback, and
only when the user provides a completer method instead of registering
the command directly with a completer class. I think this is the best
option because it not very intrusive (all the other commands will still
work normally), but especially because the whole completion code is so
messy that it would be hard to fix this without having to redesign
things.
I have regtested this on Fedora 18 x86_64, without regressions. I also
included a testcase.
gdb/ChangeLog:
2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* cli/cli-decode.c (set_cmd_completer_handle_brkchars): New
function.
(add_cmd): Set "completer_handle_brkchars" to NULL.
* cli/cli-decode.h (struct cmd_list_element)
<completer_handle_brkchars>: New field.
* command.h (completer_ftype_void): New typedef.
(set_cmd_completer_handle_brkchars): New prototype.
* completer.c (set_gdb_completion_word_break_characters): New
function.
(complete_line_internal): Call "completer_handle_brkchars"
callback from command.
* completer.h: Include "command.h".
(set_gdb_completion_word_break_characters): New prototype.
* python/py-cmd.c (cmdpy_completer_helper): New function.
(cmdpy_completer_handle_brkchars): New function.
(cmdpy_completer): Adjust to use cmdpy_completer_helper.
(cmdpy_init): Set completer_handle_brkchars to
cmdpy_completer_handle_brkchars.
gdb/testsuite/ChangeLog:
2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* gdb.python/py-completion.exp: New file.
* gdb.python/py-completion.py: Likewise.
2014-09-03 20:30:28 +00:00
|
|
|
|
|
|
|
|
|
/* Check if there was an error. */
|
|
|
|
|
if (resultobj == NULL)
|
|
|
|
|
goto done;
|
|
|
|
|
|
|
|
|
|
if (PyInt_Check (resultobj))
|
|
|
|
|
{
|
|
|
|
|
/* User code may also return one of the completion constants,
|
|
|
|
|
thus requesting that sort of completion. We are only
|
|
|
|
|
interested in this kind of return. */
|
|
|
|
|
long value;
|
|
|
|
|
|
|
|
|
|
if (!gdb_py_int_as_long (resultobj, &value))
|
|
|
|
|
{
|
|
|
|
|
/* Ignore. */
|
|
|
|
|
PyErr_Clear ();
|
|
|
|
|
}
|
|
|
|
|
else if (value >= 0 && value < (long) N_COMPLETERS)
|
|
|
|
|
{
|
|
|
|
|
/* This is the core of this function. Depending on which
|
|
|
|
|
completer type the Python function returns, we have to
|
|
|
|
|
adjust the break characters accordingly. */
|
|
|
|
|
set_gdb_completion_word_break_characters
|
|
|
|
|
(completers[value].completer);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
done:
|
|
|
|
|
|
Fix Python completion when using the "complete" command
This patch is related to PR python/16699, and is an improvement over the
patch posted here:
<https://sourceware.org/ml/gdb-patches/2014-03/msg00301.html>
Keith noticed that, when using the "complete" command on GDB to complete
a Python command, some strange things could happen. In order to
understand what can go wrong, I need to explain how the Python
completion mechanism works.
When the user requests a completion of a Python command by using TAB,
GDB will first try to determine the right set of "brkchars" that will be
used when doing the completion. This is done by actually calling the
"complete" method of the Python class. Then, when we already know the
"brkchars" that will be used, we call the "complete" method again, for
the same values.
If you read the thread mentioned above, you will see that one of the
design decisions was to make the "cmdpy_completer_helper" (which is the
function the does the actual calling of the "complete" method) cache the
first result of the completion, since this result will be used in the
second call, to do the actual completion.
The problem is that the "complete" command does not process the
brkchars, and the current Python completion mechanism (improved by the
patch mentioned above) relies on GDB trying to determine the brkchars,
and then doing the completion itself. Therefore, when we use the
"complete" command instead of doing a TAB-completion on GDB, there is a
scenario where we can use the invalid cache of a previous Python command
that was completed before. For example:
(gdb) A <TAB>
(gdb) complete B
B value1
B value10
B value2
B value3
B value4
B value5
B value6
B value7
B value8
B value9
(gdb) B <TAB>
comp1 comp2 comp4 comp6 comp8
comp10 comp3 comp5 comp7 comp9
Here, we see that "complete B " gave a different result than "B <TAB>".
The reason for that is because "A <TAB>" was called before, and its
completion results were "value*", so when GDB tried to "complete B " it
wrongly answered with the results for A. The problem here is using a
wrong cache (A's cache) for completing B.
We tried to come up with a solution that would preserve the caching
mechanism, but it wasn't really possible. So I decided to completely
remove the cache, and doing the method calling twice for every
completion. This is not optimal, but I do not think it will impact
users noticeably.
It is worth mentioning another small issue that I found. The code was
doing:
wordobj = PyUnicode_Decode (word, sizeof (word), host_charset (), NULL);
which is totally wrong, because using "sizeof" here will lead to always
the same result. So I changed this to use "strlen". The testcase also
catches this problem.
Keith kindly expanded the existing testcase to cover the problem
described above, and everything is passing.
gdb/ChangeLog:
2015-04-08 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* python/py-cmd.c (cmdpy_completer_helper): Adjust function to not
use a caching mechanism. Adjust comments and code to reflect
that. Replace 'sizeof' by 'strlen' when fetching 'wordobj'.
(cmdpy_completer_handle_brkchars): Adjust call to
cmdpy_completer_helper. Call Py_XDECREF for 'resultobj'.
(cmdpy_completer): Likewise.
gdb/testsuite/ChangeLog:
2015-04-08 Keith Seitz <keiths@redhat.com>
PR python/16699
* gdb.python/py-completion.exp: New tests for completion.
* gdb.python/py-completion.py (CompleteLimit1): New class.
(CompleteLimit2): Likewise.
(CompleteLimit3): Likewise.
(CompleteLimit4): Likewise.
(CompleteLimit5): Likewise.
(CompleteLimit6): Likewise.
(CompleteLimit7): Likewise.
2015-04-08 22:27:10 +00:00
|
|
|
|
Py_XDECREF (resultobj);
|
PR python/16699: GDB Python command completion with overriden complete vs. completer class
This PR came from a Red Hat bug that was filed recently. I checked and
it still exists on HEAD, so here's a proposed fix. Although this is
marked as a Python backend bug, this is really about the completion
mechanism used by GDB. Since this code reminds me of my first attempt
to make a good noodle, it took me quite some time to fix it in a
non-intrusive way.
The problem is triggered when one registers a completion method inside a
class in a Python script, rather than registering the command using a
completer class directly. For example, consider the following script:
class MyFirstCommand(gdb.Command):
def __init__(self):
gdb.Command.__init__(self,'myfirstcommand',gdb.COMMAND_USER,gdb.COMPLETE_FILENAME)
def invoke(self,argument,from_tty):
raise gdb.GdbError('not implemented')
class MySecondCommand(gdb.Command):
def __init__(self):
gdb.Command.__init__(self,'mysecondcommand',gdb.COMMAND_USER)
def invoke(self,argument,from_tty):
raise gdb.GdbError('not implemented')
def complete(self,text,word):
return gdb.COMPLETE_FILENAME
MyFirstCommand ()
MySecondCommand ()
When one loads this into GDB and tries to complete filenames for both
myfirstcommand and mysecondcommand, she gets:
(gdb) myfirstcommand /hom<TAB>
(gdb) myfirstcommand /home/
^
...
(gdb) mysecondcommand /hom<TAB>
(gdb) mysecondcommand /home
^
(The "^" marks the final position of the cursor after the TAB).
So we see that myfirstcommand honors the COMPLETE_FILENAME class (as
specified in the command creation), but mysecondcommand does not. After
some investigation, I found that the problem lies with the set of word
break characters that is used for each case. The set should be the same
for both commands, but it is not.
During the process of deciding which type of completion should be used,
the code in gdb/completer.c:complete_line_internal analyses the command
that requested the completion and tries to determine the type of
completion wanted by checking which completion function will be called
(e.g., filename_completer for filenames, location_completer for
locations, etc.).
This all works fine for myfirstcommand, because immediately after the
command registration the Python backend already sets its completion
function to filename_completer (which then causes the
complete_line_internal function to choose the right set of word break
chars). However, for mysecondcommand, this decision is postponed to
when the completer function is evaluated, and the Python backend uses an
internal completer (called cmdpy_completer). complete_line_internal
doesn't know about this internal completer, and can't choose the right
set of word break chars in time, which then leads to a bad decision when
completing the "/hom" word.
So, after a few attempts, I decided to create another callback in
"struct cmd_list_element" that will be responsible for handling the case
when there is an unknown completer function for complete_line_internal
to work with. So far, only the Python backend uses this callback, and
only when the user provides a completer method instead of registering
the command directly with a completer class. I think this is the best
option because it not very intrusive (all the other commands will still
work normally), but especially because the whole completion code is so
messy that it would be hard to fix this without having to redesign
things.
I have regtested this on Fedora 18 x86_64, without regressions. I also
included a testcase.
gdb/ChangeLog:
2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* cli/cli-decode.c (set_cmd_completer_handle_brkchars): New
function.
(add_cmd): Set "completer_handle_brkchars" to NULL.
* cli/cli-decode.h (struct cmd_list_element)
<completer_handle_brkchars>: New field.
* command.h (completer_ftype_void): New typedef.
(set_cmd_completer_handle_brkchars): New prototype.
* completer.c (set_gdb_completion_word_break_characters): New
function.
(complete_line_internal): Call "completer_handle_brkchars"
callback from command.
* completer.h: Include "command.h".
(set_gdb_completion_word_break_characters): New prototype.
* python/py-cmd.c (cmdpy_completer_helper): New function.
(cmdpy_completer_handle_brkchars): New function.
(cmdpy_completer): Adjust to use cmdpy_completer_helper.
(cmdpy_init): Set completer_handle_brkchars to
cmdpy_completer_handle_brkchars.
gdb/testsuite/ChangeLog:
2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* gdb.python/py-completion.exp: New file.
* gdb.python/py-completion.py: Likewise.
2014-09-03 20:30:28 +00:00
|
|
|
|
do_cleanups (cleanup);
|
|
|
|
|
}
|
|
|
|
|
|
2009-02-06 21:33:59 +00:00
|
|
|
|
/* Called by gdb for command completion. */
|
2011-09-08 19:51:27 +00:00
|
|
|
|
|
* ada-lang.c (ada_make_symbol_completion_list): Return a VEC.
* breakpoint.c (catch_syscall_completer): Return a VEC.
* cli/cli-cmds.c (complete_command): Update.
* cli/cli-decode.c (complete_on_cmdlist): Return a VEC.
(complete_on_enum): Likewise.
* command.h: Include gdb_vecs.h.
(completer_ftype): Change return type.
(complete_on_cmdlist, complete_on_enum): Likewise.
* completer.c (noop_completer, filename_completer)
(location_completer): Return a VEC.
(add_struct_fields): Remove 'nextp' argument. Change 'output'
to a VEC.
(expression_completer, complete_line_internal, complete_line)
(command_completer): Return a VEC.
(gdb_completion_word_break_characters, line_completion_function):
Update.
* completer.h: Include gdb_vecs.h.
(complete_line, noop_completer, filename_completer)
(expression_completer, location_completer, command_completer):
Update.
* f-lang.c (f_word_break_characters): Return a VEC.
* interps.c (interpreter_completer): Return a VEC.
* language.h (struct language_defn)
<la_make_symbol_completion_list>: Return a VEC.
* python/py-cmd.c (cmdpy_completer): Return a VEC.
* symtab.c (free_completion_list): Take a VEC.
(return_val_size, return_val_index): Remove.
(return_val): Now a VEC.
(completion_list_add_name): Update.
(default_make_symbol_completion_list_break_on)
(default_make_symbol_completion_list, make_symbol_completion_list)
(make_symbol_completion_list_fn, make_file_symbol_completion_list):
Return a VEC.
(add_filename_to_list): Update.
(struct add_partial_filename_data) <list_used, list_alloced>: Remove.
<list>: Now a VEC.
(maybe_add_partial_symtab_filename): Update.
(make_source_files_completion_list): Return a VEC.
* symtab.h (default_make_symbol_completion_list_break_on)
(default_make_symbol_completion_list, make_symbol_completion_list)
(make_symbol_completion_list_fn, make_file_symbol_completion_list)
(make_source_files_completion_list): Update.
2012-06-13 15:47:16 +00:00
|
|
|
|
static VEC (char_ptr) *
|
Constify strings in tracepoint.c, lookup_cmd and the completers.
This is sort of a continuation of Keith's parse_exp_1 constification
patch. It started out by undoing these bits:
@@ -754,9 +754,12 @@ validate_actionline (char **line, struct
tmp_p = p;
for (loc = t->base.loc; loc; loc = loc->next)
{
- p = tmp_p;
- exp = parse_exp_1 (&p, loc->address,
+ const char *q;
+
+ q = tmp_p;
+ exp = parse_exp_1 (&q, loc->address,
block_for_pc (loc->address), 1);
+ p = (char *) q;
and progressively making more things const upwards, fixing fallout,
rinse repeat, until GDB built again (--enable-targets=all).
That ended up constifying lookup_cmd/add_cmd and (lots of) friends,
and the completers.
I didn't try to constify the command hooks themselves, because I know
upfront there are commands that write to the command string argument,
and I think I managed to stop at a nice non-hacky split point already.
I think the only non-really-super-obvious changes are
tracepoint.c:validate_actionline, and tracepoint.c:trace_dump_actions.
The rest is just mostly about 'char *' => 'const char *', 'char **'=>
'const char **', and the occasional (e.g., deprecated_cmd_warning)
case of 'char **'=> 'const char *', where/when I noticed that nothing
actually cares about the pointer to pointer output.
Tested on x86_64 Fedora 17, native and gdbserver.
gdb/
2013-03-13 Pedro Alves <palves@redhat.com>
* ada-lang.c (struct add_partial_datum) <text, text0, word>: Make
fields const.
(ada_make_symbol_completion_list): Make "text0" parameter const.
* ax-gdb.c (agent_eval_command_one): Make "exp" parameter const.
* breakpoint.c (condition_completer): Make "text" and "word"
parameters const. Adjust.
(check_tracepoint_command): Adjust to validate_actionline
prototype change.
(catch_syscall_completer): Make "text" and "word" parameters
const.
* cli/cli-cmds.c (show_user): Make "comname" local const.
(valid_command_p): Make "command" parameter const.
(alias_command): Make "alias_prefix" and "command_prefix" locals
const.
* cli/cli-decode.c (add_cmd): Make "name" parameter const.
(add_alias_cmd): Make "name" and "oldname" parameters const.
Adjust. No longer make copy of OLDNAME.
(add_prefix_cmd, add_abbrev_prefix_cmd, add_set_or_show_cmd)
(add_setshow_cmd_full, add_setshow_enum_cmd)
(add_setshow_auto_boolean_cmd, add_setshow_boolean_cmd)
(add_setshow_filename_cmd, add_setshow_string_cmd)
(add_setshow_string_noescape_cmd)
(add_setshow_optional_filename_cmd, add_setshow_integer_cmd)
(add_setshow_uinteger_cmd, add_setshow_zinteger_cmd)
(add_setshow_zuinteger_unlimited_cmd, add_setshow_zuinteger_cmd)
(delete_cmd, add_info, add_info_alias, add_com, add_com_alias):
Make "name" parameter const.
(help_cmd): Rename "command" parameter to "arg". New const local
"command".
(find_cmd): Make "command" parameter const.
(lookup_cmd_1): Make "text" parameter pointer to const. Adjust to
deprecated_cmd_warning prototype change.
(undef_cmd_error): Make "cmdtype" parameter const.
(lookup_cmd): Make "line" parameter const.
(deprecated_cmd_warning): Change type of "text" parameter to
pointer to const char, from pointer to pointer to char. Adjust.
(lookup_cmd_composition): Make "text" parameter const.
(complete_on_cmdlist, complete_on_enum): Make "text" and "word"
parameters const.
* cli/cli-decode.h (struct cmd_list_element) <name>: Make field
const.
* cli/cli-script.c (validate_comname): Make "tem" local const.
(define_command): New const local "tem_c". Use it in calls to
lookup_cmd.
(document_command): Make "tem" and "comfull" locals const.
(show_user_1): Make "prefix" and "name" parameters const.
* cli-script.h (show_user_1): Make "prefix" and "name" parameters
const.
* command.h (add_cmd, add_alias_cmd, add_prefix_cmd)
(add_abbrev_prefix_cmd, completer_ftype, lookup_cmd, lookup_cmd_1)
(deprecated_cmd_warning, lookup_cmd_composition, add_com)
(add_com_alias, add_info, add_info_alias, complete_on_cmdlist)
(complete_on_enum, add_setshow_enum_cmd)
(add_setshow_auto_boolean_cmd, add_setshow_boolean_cmd)
(add_setshow_filename_cmd, add_setshow_string_cmd)
(add_setshow_string_noescape_cmd)
(add_setshow_optional_filename_cmd, add_setshow_integer_cmd)
(add_setshow_uinteger_cmd, add_setshow_zinteger_cmd)
(add_setshow_zuinteger_cmd, add_setshow_zuinteger_unlimited_cmd):
Change prototypes, constifying strings.
* completer.c (noop_completer, filename_completer): Make "text"
and "prefix" parameters const.
(location_completer, expression_completer)
(complete_line_internal): Make "text" and "prefix" parameters
const and adjust.
(command_completer, signal_completer): Make "text" and "prefix"
parameters const.
* completer.h (noop_completer, filename_completer)
(expression_completer, location_completer, command_completer)
(signal_completer): Change prototypes.
* corefile.c (complete_set_gnutarget): Make "text" and "word"
parameters const.
* cp-abi.c (cp_abi_completer): Likewise.
* expression.h (parse_expression_for_completion): Change
prototype.
* f-lang.c (f_make_symbol_completion_list): Make "text" and "word"
parameters const.
* infcmd.c (_initialize_infcmd): Make "cmd_name" local const.
* infrun.c (handle_completer): Make "text" and "word" parameters
const.
* interps.c (interpreter_completer): Make "text" and "word"
parameters const.
* language.h (struct language_defn)
<la_make_symbol_completion_list>: Make "text" and "word"
parameters const.
* parse.c (parse_exp_1): Move const hack to parse_exp_in_context.
(parse_exp_in_context): Rename to ...
(parse_exp_in_context_1): ... this.
(parse_exp_in_context): Reimplement, with const hack from
parse_exp_1.
(parse_expression_for_completion): Make "string" parameter const.
* printcmd.c (decode_format): Make "string_ptr" parameter pointer
to pointer to const char. Adjust.
(print_command_1): Make "exp" parameter const.
(output_command): Rename to ...
(output_command_const): ... this. Make "exp" parameter const.
(output_command): Reimplement.
(x_command): Adjust.
(display_command): Rename "exp" parameter to "arg". New "exp"
local, const version of "arg".
* python/py-auto-load.c (gdbpy_initialize_auto_load): Make
"cmd_name" local const.
* python/py-cmd.c (cmdpy_destroyer): Cast const away in xfree
call.
(cmdpy_completer): Make "text" and "word" parameters const.
(gdbpy_parse_command_name): Make "prefix_text2" local const.
* python/py-param.c (add_setshow_generic): Make "tmp_name" local
const.
* remote.c (_initialize_remote): Make "cmd_name" local const.
* symtab.c (language_search_unquoted_string): Make "text" and "p"
parameters const. Adjust.
(completion_list_add_fields): Make "sym_text", "text" and "word"
parameters const.
(struct add_name_data) <sym_text, text, word>: Make fields const.
(default_make_symbol_completion_list_break_on): Make "text" and
"word" parameters const. Adjust locals.
(default_make_symbol_completion_list)
(make_symbol_completion_list, make_symbol_completion_type)
(make_symbol_completion_list_fn): Make "text" and "word"
parameters const.
(make_file_symbol_completion_list): Make "text", "word" and
"srcfile" parameters const. Adjust locals.
(add_filename_to_list): Make "text" and "word" parameters const.
(struct add_partial_filename_data) <text, word>: Make fields
const.
(make_source_files_completion_list): Make "text" and "word"
parameters const.
* symtab.h (default_make_symbol_completion_list_break_on)
(default_make_symbol_completion_list, make_symbol_completion_list)
(make_symbol_completion_type enum type_code)
(make_symbol_completion_list_fn make_file_symbol_completion_list)
(make_source_files_completion_list): Change prototype.
* top.c (execute_command): Adjust to pass pointer to pointer to
const char to lookup_cmd, and to deprecated_cmd_warning prototype
change.
(set_verbose): Make "cmdname" local const.
* tracepoint.c (decode_agent_options): Make "exp" parameter const,
and adjust.
(validate_actionline): Make "line" parameter a pointer to const
char, and adjust.
(encode_actions_1): Make "action_exp" local const, and adjust.
(encode_actions): Adjust.
(replace_comma): Delete.
(trace_dump_actions): Make "action_exp" and "next_comma" locals
const, and adjust. Don't frob the action string while splitting
it at commas. Instead, make a copy of each split substring in
turn.
(trace_dump_command): Adjust to validate_actionline prototype
change.
* tracepoint.h (decode_agent_options, decode_agent_options)
(encode_actions, validate_actionline): Change prototypes.
* valprint.h (output_command): Delete declaration.
(output_command_const): Declare.
* value.c (function_destroyer): Cast const away in xfree call.
2013-03-13 18:34:55 +00:00
|
|
|
|
cmdpy_completer (struct cmd_list_element *command,
|
|
|
|
|
const char *text, const char *word)
|
2009-02-06 21:33:59 +00:00
|
|
|
|
{
|
PR python/16699: GDB Python command completion with overriden complete vs. completer class
This PR came from a Red Hat bug that was filed recently. I checked and
it still exists on HEAD, so here's a proposed fix. Although this is
marked as a Python backend bug, this is really about the completion
mechanism used by GDB. Since this code reminds me of my first attempt
to make a good noodle, it took me quite some time to fix it in a
non-intrusive way.
The problem is triggered when one registers a completion method inside a
class in a Python script, rather than registering the command using a
completer class directly. For example, consider the following script:
class MyFirstCommand(gdb.Command):
def __init__(self):
gdb.Command.__init__(self,'myfirstcommand',gdb.COMMAND_USER,gdb.COMPLETE_FILENAME)
def invoke(self,argument,from_tty):
raise gdb.GdbError('not implemented')
class MySecondCommand(gdb.Command):
def __init__(self):
gdb.Command.__init__(self,'mysecondcommand',gdb.COMMAND_USER)
def invoke(self,argument,from_tty):
raise gdb.GdbError('not implemented')
def complete(self,text,word):
return gdb.COMPLETE_FILENAME
MyFirstCommand ()
MySecondCommand ()
When one loads this into GDB and tries to complete filenames for both
myfirstcommand and mysecondcommand, she gets:
(gdb) myfirstcommand /hom<TAB>
(gdb) myfirstcommand /home/
^
...
(gdb) mysecondcommand /hom<TAB>
(gdb) mysecondcommand /home
^
(The "^" marks the final position of the cursor after the TAB).
So we see that myfirstcommand honors the COMPLETE_FILENAME class (as
specified in the command creation), but mysecondcommand does not. After
some investigation, I found that the problem lies with the set of word
break characters that is used for each case. The set should be the same
for both commands, but it is not.
During the process of deciding which type of completion should be used,
the code in gdb/completer.c:complete_line_internal analyses the command
that requested the completion and tries to determine the type of
completion wanted by checking which completion function will be called
(e.g., filename_completer for filenames, location_completer for
locations, etc.).
This all works fine for myfirstcommand, because immediately after the
command registration the Python backend already sets its completion
function to filename_completer (which then causes the
complete_line_internal function to choose the right set of word break
chars). However, for mysecondcommand, this decision is postponed to
when the completer function is evaluated, and the Python backend uses an
internal completer (called cmdpy_completer). complete_line_internal
doesn't know about this internal completer, and can't choose the right
set of word break chars in time, which then leads to a bad decision when
completing the "/hom" word.
So, after a few attempts, I decided to create another callback in
"struct cmd_list_element" that will be responsible for handling the case
when there is an unknown completer function for complete_line_internal
to work with. So far, only the Python backend uses this callback, and
only when the user provides a completer method instead of registering
the command directly with a completer class. I think this is the best
option because it not very intrusive (all the other commands will still
work normally), but especially because the whole completion code is so
messy that it would be hard to fix this without having to redesign
things.
I have regtested this on Fedora 18 x86_64, without regressions. I also
included a testcase.
gdb/ChangeLog:
2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* cli/cli-decode.c (set_cmd_completer_handle_brkchars): New
function.
(add_cmd): Set "completer_handle_brkchars" to NULL.
* cli/cli-decode.h (struct cmd_list_element)
<completer_handle_brkchars>: New field.
* command.h (completer_ftype_void): New typedef.
(set_cmd_completer_handle_brkchars): New prototype.
* completer.c (set_gdb_completion_word_break_characters): New
function.
(complete_line_internal): Call "completer_handle_brkchars"
callback from command.
* completer.h: Include "command.h".
(set_gdb_completion_word_break_characters): New prototype.
* python/py-cmd.c (cmdpy_completer_helper): New function.
(cmdpy_completer_handle_brkchars): New function.
(cmdpy_completer): Adjust to use cmdpy_completer_helper.
(cmdpy_init): Set completer_handle_brkchars to
cmdpy_completer_handle_brkchars.
gdb/testsuite/ChangeLog:
2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* gdb.python/py-completion.exp: New file.
* gdb.python/py-completion.py: Likewise.
2014-09-03 20:30:28 +00:00
|
|
|
|
PyObject *resultobj = NULL;
|
* ada-lang.c (ada_make_symbol_completion_list): Return a VEC.
* breakpoint.c (catch_syscall_completer): Return a VEC.
* cli/cli-cmds.c (complete_command): Update.
* cli/cli-decode.c (complete_on_cmdlist): Return a VEC.
(complete_on_enum): Likewise.
* command.h: Include gdb_vecs.h.
(completer_ftype): Change return type.
(complete_on_cmdlist, complete_on_enum): Likewise.
* completer.c (noop_completer, filename_completer)
(location_completer): Return a VEC.
(add_struct_fields): Remove 'nextp' argument. Change 'output'
to a VEC.
(expression_completer, complete_line_internal, complete_line)
(command_completer): Return a VEC.
(gdb_completion_word_break_characters, line_completion_function):
Update.
* completer.h: Include gdb_vecs.h.
(complete_line, noop_completer, filename_completer)
(expression_completer, location_completer, command_completer):
Update.
* f-lang.c (f_word_break_characters): Return a VEC.
* interps.c (interpreter_completer): Return a VEC.
* language.h (struct language_defn)
<la_make_symbol_completion_list>: Return a VEC.
* python/py-cmd.c (cmdpy_completer): Return a VEC.
* symtab.c (free_completion_list): Take a VEC.
(return_val_size, return_val_index): Remove.
(return_val): Now a VEC.
(completion_list_add_name): Update.
(default_make_symbol_completion_list_break_on)
(default_make_symbol_completion_list, make_symbol_completion_list)
(make_symbol_completion_list_fn, make_file_symbol_completion_list):
Return a VEC.
(add_filename_to_list): Update.
(struct add_partial_filename_data) <list_used, list_alloced>: Remove.
<list>: Now a VEC.
(maybe_add_partial_symtab_filename): Update.
(make_source_files_completion_list): Return a VEC.
* symtab.h (default_make_symbol_completion_list_break_on)
(default_make_symbol_completion_list, make_symbol_completion_list)
(make_symbol_completion_list_fn, make_file_symbol_completion_list)
(make_source_files_completion_list): Update.
2012-06-13 15:47:16 +00:00
|
|
|
|
VEC (char_ptr) *result = NULL;
|
2009-02-06 21:33:59 +00:00
|
|
|
|
struct cleanup *cleanup;
|
|
|
|
|
|
* python/python-internal.h (struct language_defn): Declare.
(python_gdbarch, python_language): Likewise.
(ensure_python_env): Add prototype.
(make_cleanup_py_restore_gil): Remove prototype.
* python/python.c: Include "arch-utils.h", "value.h" and "language.h".
(python_gdbarch, python_language): New global variables.
(struct python_env): New data type.
(ensure_python_env, restore_python_env): New functions.
(eval_python_from_control_command): Call ensure_python_env to
install current architecture and language.
(python_command, gdbpy_new_objfile): Likewise.
* python/python-cmd.c: Include "arch-utils.h" and "language.h".
(cmdpy_destroyer, cmdpy_function, cmdpy_completer): Call
ensure_python_env.
* python/python-type.c (clean_up_objfile_types): Likewise.
* python/python-objfile.c: Include "language.h".
(clean_up_objfile): Call ensure_python_env.
* python/python-prettyprint.c (apply_val_pretty_printer): Likewise.
(apply_varobj_pretty_printer): Do not call PyGILState_Ensure.
* varobj.c (varobj_ensure_python_env): New helper function.
(varobj_get_display_hint, update_dynamic_varobj_children,
install_default_visualizer, varobj_set_visualizer, free_variable,
value_get_print_value): Call it.
(value_get_print_value): Add varobj argument instead of pretty
printer argument. Update all callers.
* python/python-utils.c (py_gil_restore, make_cleanup_py_restore_gil):
Remove.
* value.h (internal_function_fn): Add GDBARCH and LANGUAGE argument.
(call_internal_function): Likewise.
* value.c (call_internal_function): Likewise. Pass to handler.
* eval.c (evaluate_subexp_standard): Update call.
* python/python-function.c: Include "language.h".
(fnpy_call): Add GDBARCH and LANGAUAGE arguments and call
make_cleanup_python_env.
* python/python-value.c (builtin_type_pyint, builtin_type_pyfloat,
builtin_type_pylong, builtin_type_pybool, builtin_type_pychar,
valpy_str): Use python_gdbarch and python_language instead of
current_gdbarch and current_language.
* python/python-type.c (typy_lookup_typename): Likewise.
2009-07-02 17:04:23 +00:00
|
|
|
|
cleanup = ensure_python_env (get_current_arch (), current_language);
|
2009-02-06 21:33:59 +00:00
|
|
|
|
|
PR python/16699: GDB Python command completion with overriden complete vs. completer class
This PR came from a Red Hat bug that was filed recently. I checked and
it still exists on HEAD, so here's a proposed fix. Although this is
marked as a Python backend bug, this is really about the completion
mechanism used by GDB. Since this code reminds me of my first attempt
to make a good noodle, it took me quite some time to fix it in a
non-intrusive way.
The problem is triggered when one registers a completion method inside a
class in a Python script, rather than registering the command using a
completer class directly. For example, consider the following script:
class MyFirstCommand(gdb.Command):
def __init__(self):
gdb.Command.__init__(self,'myfirstcommand',gdb.COMMAND_USER,gdb.COMPLETE_FILENAME)
def invoke(self,argument,from_tty):
raise gdb.GdbError('not implemented')
class MySecondCommand(gdb.Command):
def __init__(self):
gdb.Command.__init__(self,'mysecondcommand',gdb.COMMAND_USER)
def invoke(self,argument,from_tty):
raise gdb.GdbError('not implemented')
def complete(self,text,word):
return gdb.COMPLETE_FILENAME
MyFirstCommand ()
MySecondCommand ()
When one loads this into GDB and tries to complete filenames for both
myfirstcommand and mysecondcommand, she gets:
(gdb) myfirstcommand /hom<TAB>
(gdb) myfirstcommand /home/
^
...
(gdb) mysecondcommand /hom<TAB>
(gdb) mysecondcommand /home
^
(The "^" marks the final position of the cursor after the TAB).
So we see that myfirstcommand honors the COMPLETE_FILENAME class (as
specified in the command creation), but mysecondcommand does not. After
some investigation, I found that the problem lies with the set of word
break characters that is used for each case. The set should be the same
for both commands, but it is not.
During the process of deciding which type of completion should be used,
the code in gdb/completer.c:complete_line_internal analyses the command
that requested the completion and tries to determine the type of
completion wanted by checking which completion function will be called
(e.g., filename_completer for filenames, location_completer for
locations, etc.).
This all works fine for myfirstcommand, because immediately after the
command registration the Python backend already sets its completion
function to filename_completer (which then causes the
complete_line_internal function to choose the right set of word break
chars). However, for mysecondcommand, this decision is postponed to
when the completer function is evaluated, and the Python backend uses an
internal completer (called cmdpy_completer). complete_line_internal
doesn't know about this internal completer, and can't choose the right
set of word break chars in time, which then leads to a bad decision when
completing the "/hom" word.
So, after a few attempts, I decided to create another callback in
"struct cmd_list_element" that will be responsible for handling the case
when there is an unknown completer function for complete_line_internal
to work with. So far, only the Python backend uses this callback, and
only when the user provides a completer method instead of registering
the command directly with a completer class. I think this is the best
option because it not very intrusive (all the other commands will still
work normally), but especially because the whole completion code is so
messy that it would be hard to fix this without having to redesign
things.
I have regtested this on Fedora 18 x86_64, without regressions. I also
included a testcase.
gdb/ChangeLog:
2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* cli/cli-decode.c (set_cmd_completer_handle_brkchars): New
function.
(add_cmd): Set "completer_handle_brkchars" to NULL.
* cli/cli-decode.h (struct cmd_list_element)
<completer_handle_brkchars>: New field.
* command.h (completer_ftype_void): New typedef.
(set_cmd_completer_handle_brkchars): New prototype.
* completer.c (set_gdb_completion_word_break_characters): New
function.
(complete_line_internal): Call "completer_handle_brkchars"
callback from command.
* completer.h: Include "command.h".
(set_gdb_completion_word_break_characters): New prototype.
* python/py-cmd.c (cmdpy_completer_helper): New function.
(cmdpy_completer_handle_brkchars): New function.
(cmdpy_completer): Adjust to use cmdpy_completer_helper.
(cmdpy_init): Set completer_handle_brkchars to
cmdpy_completer_handle_brkchars.
gdb/testsuite/ChangeLog:
2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* gdb.python/py-completion.exp: New file.
* gdb.python/py-completion.py: Likewise.
2014-09-03 20:30:28 +00:00
|
|
|
|
/* Calling our helper to obtain the PyObject of the Python
|
|
|
|
|
function. */
|
Fix Python completion when using the "complete" command
This patch is related to PR python/16699, and is an improvement over the
patch posted here:
<https://sourceware.org/ml/gdb-patches/2014-03/msg00301.html>
Keith noticed that, when using the "complete" command on GDB to complete
a Python command, some strange things could happen. In order to
understand what can go wrong, I need to explain how the Python
completion mechanism works.
When the user requests a completion of a Python command by using TAB,
GDB will first try to determine the right set of "brkchars" that will be
used when doing the completion. This is done by actually calling the
"complete" method of the Python class. Then, when we already know the
"brkchars" that will be used, we call the "complete" method again, for
the same values.
If you read the thread mentioned above, you will see that one of the
design decisions was to make the "cmdpy_completer_helper" (which is the
function the does the actual calling of the "complete" method) cache the
first result of the completion, since this result will be used in the
second call, to do the actual completion.
The problem is that the "complete" command does not process the
brkchars, and the current Python completion mechanism (improved by the
patch mentioned above) relies on GDB trying to determine the brkchars,
and then doing the completion itself. Therefore, when we use the
"complete" command instead of doing a TAB-completion on GDB, there is a
scenario where we can use the invalid cache of a previous Python command
that was completed before. For example:
(gdb) A <TAB>
(gdb) complete B
B value1
B value10
B value2
B value3
B value4
B value5
B value6
B value7
B value8
B value9
(gdb) B <TAB>
comp1 comp2 comp4 comp6 comp8
comp10 comp3 comp5 comp7 comp9
Here, we see that "complete B " gave a different result than "B <TAB>".
The reason for that is because "A <TAB>" was called before, and its
completion results were "value*", so when GDB tried to "complete B " it
wrongly answered with the results for A. The problem here is using a
wrong cache (A's cache) for completing B.
We tried to come up with a solution that would preserve the caching
mechanism, but it wasn't really possible. So I decided to completely
remove the cache, and doing the method calling twice for every
completion. This is not optimal, but I do not think it will impact
users noticeably.
It is worth mentioning another small issue that I found. The code was
doing:
wordobj = PyUnicode_Decode (word, sizeof (word), host_charset (), NULL);
which is totally wrong, because using "sizeof" here will lead to always
the same result. So I changed this to use "strlen". The testcase also
catches this problem.
Keith kindly expanded the existing testcase to cover the problem
described above, and everything is passing.
gdb/ChangeLog:
2015-04-08 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* python/py-cmd.c (cmdpy_completer_helper): Adjust function to not
use a caching mechanism. Adjust comments and code to reflect
that. Replace 'sizeof' by 'strlen' when fetching 'wordobj'.
(cmdpy_completer_handle_brkchars): Adjust call to
cmdpy_completer_helper. Call Py_XDECREF for 'resultobj'.
(cmdpy_completer): Likewise.
gdb/testsuite/ChangeLog:
2015-04-08 Keith Seitz <keiths@redhat.com>
PR python/16699
* gdb.python/py-completion.exp: New tests for completion.
* gdb.python/py-completion.py (CompleteLimit1): New class.
(CompleteLimit2): Likewise.
(CompleteLimit3): Likewise.
(CompleteLimit4): Likewise.
(CompleteLimit5): Likewise.
(CompleteLimit6): Likewise.
(CompleteLimit7): Likewise.
2015-04-08 22:27:10 +00:00
|
|
|
|
resultobj = cmdpy_completer_helper (command, text, word);
|
2009-02-06 21:33:59 +00:00
|
|
|
|
|
PR python/16699: GDB Python command completion with overriden complete vs. completer class
This PR came from a Red Hat bug that was filed recently. I checked and
it still exists on HEAD, so here's a proposed fix. Although this is
marked as a Python backend bug, this is really about the completion
mechanism used by GDB. Since this code reminds me of my first attempt
to make a good noodle, it took me quite some time to fix it in a
non-intrusive way.
The problem is triggered when one registers a completion method inside a
class in a Python script, rather than registering the command using a
completer class directly. For example, consider the following script:
class MyFirstCommand(gdb.Command):
def __init__(self):
gdb.Command.__init__(self,'myfirstcommand',gdb.COMMAND_USER,gdb.COMPLETE_FILENAME)
def invoke(self,argument,from_tty):
raise gdb.GdbError('not implemented')
class MySecondCommand(gdb.Command):
def __init__(self):
gdb.Command.__init__(self,'mysecondcommand',gdb.COMMAND_USER)
def invoke(self,argument,from_tty):
raise gdb.GdbError('not implemented')
def complete(self,text,word):
return gdb.COMPLETE_FILENAME
MyFirstCommand ()
MySecondCommand ()
When one loads this into GDB and tries to complete filenames for both
myfirstcommand and mysecondcommand, she gets:
(gdb) myfirstcommand /hom<TAB>
(gdb) myfirstcommand /home/
^
...
(gdb) mysecondcommand /hom<TAB>
(gdb) mysecondcommand /home
^
(The "^" marks the final position of the cursor after the TAB).
So we see that myfirstcommand honors the COMPLETE_FILENAME class (as
specified in the command creation), but mysecondcommand does not. After
some investigation, I found that the problem lies with the set of word
break characters that is used for each case. The set should be the same
for both commands, but it is not.
During the process of deciding which type of completion should be used,
the code in gdb/completer.c:complete_line_internal analyses the command
that requested the completion and tries to determine the type of
completion wanted by checking which completion function will be called
(e.g., filename_completer for filenames, location_completer for
locations, etc.).
This all works fine for myfirstcommand, because immediately after the
command registration the Python backend already sets its completion
function to filename_completer (which then causes the
complete_line_internal function to choose the right set of word break
chars). However, for mysecondcommand, this decision is postponed to
when the completer function is evaluated, and the Python backend uses an
internal completer (called cmdpy_completer). complete_line_internal
doesn't know about this internal completer, and can't choose the right
set of word break chars in time, which then leads to a bad decision when
completing the "/hom" word.
So, after a few attempts, I decided to create another callback in
"struct cmd_list_element" that will be responsible for handling the case
when there is an unknown completer function for complete_line_internal
to work with. So far, only the Python backend uses this callback, and
only when the user provides a completer method instead of registering
the command directly with a completer class. I think this is the best
option because it not very intrusive (all the other commands will still
work normally), but especially because the whole completion code is so
messy that it would be hard to fix this without having to redesign
things.
I have regtested this on Fedora 18 x86_64, without regressions. I also
included a testcase.
gdb/ChangeLog:
2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* cli/cli-decode.c (set_cmd_completer_handle_brkchars): New
function.
(add_cmd): Set "completer_handle_brkchars" to NULL.
* cli/cli-decode.h (struct cmd_list_element)
<completer_handle_brkchars>: New field.
* command.h (completer_ftype_void): New typedef.
(set_cmd_completer_handle_brkchars): New prototype.
* completer.c (set_gdb_completion_word_break_characters): New
function.
(complete_line_internal): Call "completer_handle_brkchars"
callback from command.
* completer.h: Include "command.h".
(set_gdb_completion_word_break_characters): New prototype.
* python/py-cmd.c (cmdpy_completer_helper): New function.
(cmdpy_completer_handle_brkchars): New function.
(cmdpy_completer): Adjust to use cmdpy_completer_helper.
(cmdpy_init): Set completer_handle_brkchars to
cmdpy_completer_handle_brkchars.
gdb/testsuite/ChangeLog:
2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* gdb.python/py-completion.exp: New file.
* gdb.python/py-completion.py: Likewise.
2014-09-03 20:30:28 +00:00
|
|
|
|
/* If the result object of calling the Python function is NULL, it
|
|
|
|
|
means that there was an error. In this case, just give up and
|
|
|
|
|
return NULL. */
|
|
|
|
|
if (resultobj == NULL)
|
|
|
|
|
goto done;
|
2009-02-06 21:33:59 +00:00
|
|
|
|
|
|
|
|
|
result = NULL;
|
2013-05-20 20:21:55 +00:00
|
|
|
|
if (PyInt_Check (resultobj))
|
2009-02-06 21:33:59 +00:00
|
|
|
|
{
|
2013-05-20 20:21:55 +00:00
|
|
|
|
/* User code may also return one of the completion constants,
|
|
|
|
|
thus requesting that sort of completion. */
|
|
|
|
|
long value;
|
|
|
|
|
|
|
|
|
|
if (! gdb_py_int_as_long (resultobj, &value))
|
|
|
|
|
{
|
|
|
|
|
/* Ignore. */
|
|
|
|
|
PyErr_Clear ();
|
|
|
|
|
}
|
|
|
|
|
else if (value >= 0 && value < (long) N_COMPLETERS)
|
|
|
|
|
result = completers[value].completer (command, text, word);
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
{
|
|
|
|
|
PyObject *iter = PyObject_GetIter (resultobj);
|
|
|
|
|
PyObject *elt;
|
2010-05-17 21:23:25 +00:00
|
|
|
|
|
2013-05-20 20:21:55 +00:00
|
|
|
|
if (iter == NULL)
|
2009-02-06 21:33:59 +00:00
|
|
|
|
goto done;
|
|
|
|
|
|
2013-05-20 20:21:55 +00:00
|
|
|
|
while ((elt = PyIter_Next (iter)) != NULL)
|
2009-02-06 21:33:59 +00:00
|
|
|
|
{
|
* ada-lang.c (ada_make_symbol_completion_list): Return a VEC.
* breakpoint.c (catch_syscall_completer): Return a VEC.
* cli/cli-cmds.c (complete_command): Update.
* cli/cli-decode.c (complete_on_cmdlist): Return a VEC.
(complete_on_enum): Likewise.
* command.h: Include gdb_vecs.h.
(completer_ftype): Change return type.
(complete_on_cmdlist, complete_on_enum): Likewise.
* completer.c (noop_completer, filename_completer)
(location_completer): Return a VEC.
(add_struct_fields): Remove 'nextp' argument. Change 'output'
to a VEC.
(expression_completer, complete_line_internal, complete_line)
(command_completer): Return a VEC.
(gdb_completion_word_break_characters, line_completion_function):
Update.
* completer.h: Include gdb_vecs.h.
(complete_line, noop_completer, filename_completer)
(expression_completer, location_completer, command_completer):
Update.
* f-lang.c (f_word_break_characters): Return a VEC.
* interps.c (interpreter_completer): Return a VEC.
* language.h (struct language_defn)
<la_make_symbol_completion_list>: Return a VEC.
* python/py-cmd.c (cmdpy_completer): Return a VEC.
* symtab.c (free_completion_list): Take a VEC.
(return_val_size, return_val_index): Remove.
(return_val): Now a VEC.
(completion_list_add_name): Update.
(default_make_symbol_completion_list_break_on)
(default_make_symbol_completion_list, make_symbol_completion_list)
(make_symbol_completion_list_fn, make_file_symbol_completion_list):
Return a VEC.
(add_filename_to_list): Update.
(struct add_partial_filename_data) <list_used, list_alloced>: Remove.
<list>: Now a VEC.
(maybe_add_partial_symtab_filename): Update.
(make_source_files_completion_list): Return a VEC.
* symtab.h (default_make_symbol_completion_list_break_on)
(default_make_symbol_completion_list, make_symbol_completion_list)
(make_symbol_completion_list_fn, make_file_symbol_completion_list)
(make_source_files_completion_list): Update.
2012-06-13 15:47:16 +00:00
|
|
|
|
char *item;
|
2010-05-17 21:23:25 +00:00
|
|
|
|
|
2013-05-20 20:21:55 +00:00
|
|
|
|
if (! gdbpy_is_string (elt))
|
2009-02-06 21:33:59 +00:00
|
|
|
|
{
|
|
|
|
|
/* Skip problem elements. */
|
2013-05-20 20:21:55 +00:00
|
|
|
|
Py_DECREF (elt);
|
2009-02-06 21:33:59 +00:00
|
|
|
|
continue;
|
|
|
|
|
}
|
* ada-lang.c (ada_make_symbol_completion_list): Return a VEC.
* breakpoint.c (catch_syscall_completer): Return a VEC.
* cli/cli-cmds.c (complete_command): Update.
* cli/cli-decode.c (complete_on_cmdlist): Return a VEC.
(complete_on_enum): Likewise.
* command.h: Include gdb_vecs.h.
(completer_ftype): Change return type.
(complete_on_cmdlist, complete_on_enum): Likewise.
* completer.c (noop_completer, filename_completer)
(location_completer): Return a VEC.
(add_struct_fields): Remove 'nextp' argument. Change 'output'
to a VEC.
(expression_completer, complete_line_internal, complete_line)
(command_completer): Return a VEC.
(gdb_completion_word_break_characters, line_completion_function):
Update.
* completer.h: Include gdb_vecs.h.
(complete_line, noop_completer, filename_completer)
(expression_completer, location_completer, command_completer):
Update.
* f-lang.c (f_word_break_characters): Return a VEC.
* interps.c (interpreter_completer): Return a VEC.
* language.h (struct language_defn)
<la_make_symbol_completion_list>: Return a VEC.
* python/py-cmd.c (cmdpy_completer): Return a VEC.
* symtab.c (free_completion_list): Take a VEC.
(return_val_size, return_val_index): Remove.
(return_val): Now a VEC.
(completion_list_add_name): Update.
(default_make_symbol_completion_list_break_on)
(default_make_symbol_completion_list, make_symbol_completion_list)
(make_symbol_completion_list_fn, make_file_symbol_completion_list):
Return a VEC.
(add_filename_to_list): Update.
(struct add_partial_filename_data) <list_used, list_alloced>: Remove.
<list>: Now a VEC.
(maybe_add_partial_symtab_filename): Update.
(make_source_files_completion_list): Return a VEC.
* symtab.h (default_make_symbol_completion_list_break_on)
(default_make_symbol_completion_list, make_symbol_completion_list)
(make_symbol_completion_list_fn, make_file_symbol_completion_list)
(make_source_files_completion_list): Update.
2012-06-13 15:47:16 +00:00
|
|
|
|
item = python_string_to_host_string (elt);
|
2013-05-20 20:21:55 +00:00
|
|
|
|
Py_DECREF (elt);
|
* ada-lang.c (ada_make_symbol_completion_list): Return a VEC.
* breakpoint.c (catch_syscall_completer): Return a VEC.
* cli/cli-cmds.c (complete_command): Update.
* cli/cli-decode.c (complete_on_cmdlist): Return a VEC.
(complete_on_enum): Likewise.
* command.h: Include gdb_vecs.h.
(completer_ftype): Change return type.
(complete_on_cmdlist, complete_on_enum): Likewise.
* completer.c (noop_completer, filename_completer)
(location_completer): Return a VEC.
(add_struct_fields): Remove 'nextp' argument. Change 'output'
to a VEC.
(expression_completer, complete_line_internal, complete_line)
(command_completer): Return a VEC.
(gdb_completion_word_break_characters, line_completion_function):
Update.
* completer.h: Include gdb_vecs.h.
(complete_line, noop_completer, filename_completer)
(expression_completer, location_completer, command_completer):
Update.
* f-lang.c (f_word_break_characters): Return a VEC.
* interps.c (interpreter_completer): Return a VEC.
* language.h (struct language_defn)
<la_make_symbol_completion_list>: Return a VEC.
* python/py-cmd.c (cmdpy_completer): Return a VEC.
* symtab.c (free_completion_list): Take a VEC.
(return_val_size, return_val_index): Remove.
(return_val): Now a VEC.
(completion_list_add_name): Update.
(default_make_symbol_completion_list_break_on)
(default_make_symbol_completion_list, make_symbol_completion_list)
(make_symbol_completion_list_fn, make_file_symbol_completion_list):
Return a VEC.
(add_filename_to_list): Update.
(struct add_partial_filename_data) <list_used, list_alloced>: Remove.
<list>: Now a VEC.
(maybe_add_partial_symtab_filename): Update.
(make_source_files_completion_list): Return a VEC.
* symtab.h (default_make_symbol_completion_list_break_on)
(default_make_symbol_completion_list, make_symbol_completion_list)
(make_symbol_completion_list_fn, make_file_symbol_completion_list)
(make_source_files_completion_list): Update.
2012-06-13 15:47:16 +00:00
|
|
|
|
if (item == NULL)
|
2010-10-13 13:24:40 +00:00
|
|
|
|
{
|
|
|
|
|
/* Skip problem elements. */
|
|
|
|
|
PyErr_Clear ();
|
|
|
|
|
continue;
|
|
|
|
|
}
|
* ada-lang.c (ada_make_symbol_completion_list): Return a VEC.
* breakpoint.c (catch_syscall_completer): Return a VEC.
* cli/cli-cmds.c (complete_command): Update.
* cli/cli-decode.c (complete_on_cmdlist): Return a VEC.
(complete_on_enum): Likewise.
* command.h: Include gdb_vecs.h.
(completer_ftype): Change return type.
(complete_on_cmdlist, complete_on_enum): Likewise.
* completer.c (noop_completer, filename_completer)
(location_completer): Return a VEC.
(add_struct_fields): Remove 'nextp' argument. Change 'output'
to a VEC.
(expression_completer, complete_line_internal, complete_line)
(command_completer): Return a VEC.
(gdb_completion_word_break_characters, line_completion_function):
Update.
* completer.h: Include gdb_vecs.h.
(complete_line, noop_completer, filename_completer)
(expression_completer, location_completer, command_completer):
Update.
* f-lang.c (f_word_break_characters): Return a VEC.
* interps.c (interpreter_completer): Return a VEC.
* language.h (struct language_defn)
<la_make_symbol_completion_list>: Return a VEC.
* python/py-cmd.c (cmdpy_completer): Return a VEC.
* symtab.c (free_completion_list): Take a VEC.
(return_val_size, return_val_index): Remove.
(return_val): Now a VEC.
(completion_list_add_name): Update.
(default_make_symbol_completion_list_break_on)
(default_make_symbol_completion_list, make_symbol_completion_list)
(make_symbol_completion_list_fn, make_file_symbol_completion_list):
Return a VEC.
(add_filename_to_list): Update.
(struct add_partial_filename_data) <list_used, list_alloced>: Remove.
<list>: Now a VEC.
(maybe_add_partial_symtab_filename): Update.
(make_source_files_completion_list): Return a VEC.
* symtab.h (default_make_symbol_completion_list_break_on)
(default_make_symbol_completion_list, make_symbol_completion_list)
(make_symbol_completion_list_fn, make_file_symbol_completion_list)
(make_source_files_completion_list): Update.
2012-06-13 15:47:16 +00:00
|
|
|
|
VEC_safe_push (char_ptr, result, item);
|
2009-02-06 21:33:59 +00:00
|
|
|
|
}
|
2010-05-17 21:23:25 +00:00
|
|
|
|
|
2013-05-20 20:21:55 +00:00
|
|
|
|
Py_DECREF (iter);
|
|
|
|
|
|
|
|
|
|
/* If we got some results, ignore problems. Otherwise, report
|
|
|
|
|
the problem. */
|
|
|
|
|
if (result != NULL && PyErr_Occurred ())
|
|
|
|
|
PyErr_Clear ();
|
2009-02-06 21:33:59 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
done:
|
|
|
|
|
|
Fix Python completion when using the "complete" command
This patch is related to PR python/16699, and is an improvement over the
patch posted here:
<https://sourceware.org/ml/gdb-patches/2014-03/msg00301.html>
Keith noticed that, when using the "complete" command on GDB to complete
a Python command, some strange things could happen. In order to
understand what can go wrong, I need to explain how the Python
completion mechanism works.
When the user requests a completion of a Python command by using TAB,
GDB will first try to determine the right set of "brkchars" that will be
used when doing the completion. This is done by actually calling the
"complete" method of the Python class. Then, when we already know the
"brkchars" that will be used, we call the "complete" method again, for
the same values.
If you read the thread mentioned above, you will see that one of the
design decisions was to make the "cmdpy_completer_helper" (which is the
function the does the actual calling of the "complete" method) cache the
first result of the completion, since this result will be used in the
second call, to do the actual completion.
The problem is that the "complete" command does not process the
brkchars, and the current Python completion mechanism (improved by the
patch mentioned above) relies on GDB trying to determine the brkchars,
and then doing the completion itself. Therefore, when we use the
"complete" command instead of doing a TAB-completion on GDB, there is a
scenario where we can use the invalid cache of a previous Python command
that was completed before. For example:
(gdb) A <TAB>
(gdb) complete B
B value1
B value10
B value2
B value3
B value4
B value5
B value6
B value7
B value8
B value9
(gdb) B <TAB>
comp1 comp2 comp4 comp6 comp8
comp10 comp3 comp5 comp7 comp9
Here, we see that "complete B " gave a different result than "B <TAB>".
The reason for that is because "A <TAB>" was called before, and its
completion results were "value*", so when GDB tried to "complete B " it
wrongly answered with the results for A. The problem here is using a
wrong cache (A's cache) for completing B.
We tried to come up with a solution that would preserve the caching
mechanism, but it wasn't really possible. So I decided to completely
remove the cache, and doing the method calling twice for every
completion. This is not optimal, but I do not think it will impact
users noticeably.
It is worth mentioning another small issue that I found. The code was
doing:
wordobj = PyUnicode_Decode (word, sizeof (word), host_charset (), NULL);
which is totally wrong, because using "sizeof" here will lead to always
the same result. So I changed this to use "strlen". The testcase also
catches this problem.
Keith kindly expanded the existing testcase to cover the problem
described above, and everything is passing.
gdb/ChangeLog:
2015-04-08 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* python/py-cmd.c (cmdpy_completer_helper): Adjust function to not
use a caching mechanism. Adjust comments and code to reflect
that. Replace 'sizeof' by 'strlen' when fetching 'wordobj'.
(cmdpy_completer_handle_brkchars): Adjust call to
cmdpy_completer_helper. Call Py_XDECREF for 'resultobj'.
(cmdpy_completer): Likewise.
gdb/testsuite/ChangeLog:
2015-04-08 Keith Seitz <keiths@redhat.com>
PR python/16699
* gdb.python/py-completion.exp: New tests for completion.
* gdb.python/py-completion.py (CompleteLimit1): New class.
(CompleteLimit2): Likewise.
(CompleteLimit3): Likewise.
(CompleteLimit4): Likewise.
(CompleteLimit5): Likewise.
(CompleteLimit6): Likewise.
(CompleteLimit7): Likewise.
2015-04-08 22:27:10 +00:00
|
|
|
|
Py_XDECREF (resultobj);
|
2009-02-06 21:33:59 +00:00
|
|
|
|
do_cleanups (cleanup);
|
|
|
|
|
|
|
|
|
|
return result;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Helper for cmdpy_init which locates the command list to use and
|
|
|
|
|
pulls out the command name.
|
2013-11-29 20:00:47 +00:00
|
|
|
|
|
2011-09-08 19:51:27 +00:00
|
|
|
|
NAME is the command name list. The final word in the list is the
|
2009-02-06 21:33:59 +00:00
|
|
|
|
name of the new command. All earlier words must be existing prefix
|
|
|
|
|
commands.
|
|
|
|
|
|
|
|
|
|
*BASE_LIST is set to the final prefix command's list of
|
|
|
|
|
*sub-commands.
|
2013-11-29 20:00:47 +00:00
|
|
|
|
|
2010-04-29 15:45:57 +00:00
|
|
|
|
START_LIST is the list in which the search starts.
|
|
|
|
|
|
2009-02-06 21:33:59 +00:00
|
|
|
|
This function returns the xmalloc()d name of the new command. On
|
|
|
|
|
error sets the Python error and returns NULL. */
|
2011-09-08 19:51:27 +00:00
|
|
|
|
|
2010-04-29 15:45:57 +00:00
|
|
|
|
char *
|
2011-09-08 19:51:27 +00:00
|
|
|
|
gdbpy_parse_command_name (const char *name,
|
2010-04-29 15:45:57 +00:00
|
|
|
|
struct cmd_list_element ***base_list,
|
|
|
|
|
struct cmd_list_element **start_list)
|
2009-02-06 21:33:59 +00:00
|
|
|
|
{
|
|
|
|
|
struct cmd_list_element *elt;
|
2011-09-08 19:51:27 +00:00
|
|
|
|
int len = strlen (name);
|
2009-02-06 21:33:59 +00:00
|
|
|
|
int i, lastchar;
|
Constify strings in tracepoint.c, lookup_cmd and the completers.
This is sort of a continuation of Keith's parse_exp_1 constification
patch. It started out by undoing these bits:
@@ -754,9 +754,12 @@ validate_actionline (char **line, struct
tmp_p = p;
for (loc = t->base.loc; loc; loc = loc->next)
{
- p = tmp_p;
- exp = parse_exp_1 (&p, loc->address,
+ const char *q;
+
+ q = tmp_p;
+ exp = parse_exp_1 (&q, loc->address,
block_for_pc (loc->address), 1);
+ p = (char *) q;
and progressively making more things const upwards, fixing fallout,
rinse repeat, until GDB built again (--enable-targets=all).
That ended up constifying lookup_cmd/add_cmd and (lots of) friends,
and the completers.
I didn't try to constify the command hooks themselves, because I know
upfront there are commands that write to the command string argument,
and I think I managed to stop at a nice non-hacky split point already.
I think the only non-really-super-obvious changes are
tracepoint.c:validate_actionline, and tracepoint.c:trace_dump_actions.
The rest is just mostly about 'char *' => 'const char *', 'char **'=>
'const char **', and the occasional (e.g., deprecated_cmd_warning)
case of 'char **'=> 'const char *', where/when I noticed that nothing
actually cares about the pointer to pointer output.
Tested on x86_64 Fedora 17, native and gdbserver.
gdb/
2013-03-13 Pedro Alves <palves@redhat.com>
* ada-lang.c (struct add_partial_datum) <text, text0, word>: Make
fields const.
(ada_make_symbol_completion_list): Make "text0" parameter const.
* ax-gdb.c (agent_eval_command_one): Make "exp" parameter const.
* breakpoint.c (condition_completer): Make "text" and "word"
parameters const. Adjust.
(check_tracepoint_command): Adjust to validate_actionline
prototype change.
(catch_syscall_completer): Make "text" and "word" parameters
const.
* cli/cli-cmds.c (show_user): Make "comname" local const.
(valid_command_p): Make "command" parameter const.
(alias_command): Make "alias_prefix" and "command_prefix" locals
const.
* cli/cli-decode.c (add_cmd): Make "name" parameter const.
(add_alias_cmd): Make "name" and "oldname" parameters const.
Adjust. No longer make copy of OLDNAME.
(add_prefix_cmd, add_abbrev_prefix_cmd, add_set_or_show_cmd)
(add_setshow_cmd_full, add_setshow_enum_cmd)
(add_setshow_auto_boolean_cmd, add_setshow_boolean_cmd)
(add_setshow_filename_cmd, add_setshow_string_cmd)
(add_setshow_string_noescape_cmd)
(add_setshow_optional_filename_cmd, add_setshow_integer_cmd)
(add_setshow_uinteger_cmd, add_setshow_zinteger_cmd)
(add_setshow_zuinteger_unlimited_cmd, add_setshow_zuinteger_cmd)
(delete_cmd, add_info, add_info_alias, add_com, add_com_alias):
Make "name" parameter const.
(help_cmd): Rename "command" parameter to "arg". New const local
"command".
(find_cmd): Make "command" parameter const.
(lookup_cmd_1): Make "text" parameter pointer to const. Adjust to
deprecated_cmd_warning prototype change.
(undef_cmd_error): Make "cmdtype" parameter const.
(lookup_cmd): Make "line" parameter const.
(deprecated_cmd_warning): Change type of "text" parameter to
pointer to const char, from pointer to pointer to char. Adjust.
(lookup_cmd_composition): Make "text" parameter const.
(complete_on_cmdlist, complete_on_enum): Make "text" and "word"
parameters const.
* cli/cli-decode.h (struct cmd_list_element) <name>: Make field
const.
* cli/cli-script.c (validate_comname): Make "tem" local const.
(define_command): New const local "tem_c". Use it in calls to
lookup_cmd.
(document_command): Make "tem" and "comfull" locals const.
(show_user_1): Make "prefix" and "name" parameters const.
* cli-script.h (show_user_1): Make "prefix" and "name" parameters
const.
* command.h (add_cmd, add_alias_cmd, add_prefix_cmd)
(add_abbrev_prefix_cmd, completer_ftype, lookup_cmd, lookup_cmd_1)
(deprecated_cmd_warning, lookup_cmd_composition, add_com)
(add_com_alias, add_info, add_info_alias, complete_on_cmdlist)
(complete_on_enum, add_setshow_enum_cmd)
(add_setshow_auto_boolean_cmd, add_setshow_boolean_cmd)
(add_setshow_filename_cmd, add_setshow_string_cmd)
(add_setshow_string_noescape_cmd)
(add_setshow_optional_filename_cmd, add_setshow_integer_cmd)
(add_setshow_uinteger_cmd, add_setshow_zinteger_cmd)
(add_setshow_zuinteger_cmd, add_setshow_zuinteger_unlimited_cmd):
Change prototypes, constifying strings.
* completer.c (noop_completer, filename_completer): Make "text"
and "prefix" parameters const.
(location_completer, expression_completer)
(complete_line_internal): Make "text" and "prefix" parameters
const and adjust.
(command_completer, signal_completer): Make "text" and "prefix"
parameters const.
* completer.h (noop_completer, filename_completer)
(expression_completer, location_completer, command_completer)
(signal_completer): Change prototypes.
* corefile.c (complete_set_gnutarget): Make "text" and "word"
parameters const.
* cp-abi.c (cp_abi_completer): Likewise.
* expression.h (parse_expression_for_completion): Change
prototype.
* f-lang.c (f_make_symbol_completion_list): Make "text" and "word"
parameters const.
* infcmd.c (_initialize_infcmd): Make "cmd_name" local const.
* infrun.c (handle_completer): Make "text" and "word" parameters
const.
* interps.c (interpreter_completer): Make "text" and "word"
parameters const.
* language.h (struct language_defn)
<la_make_symbol_completion_list>: Make "text" and "word"
parameters const.
* parse.c (parse_exp_1): Move const hack to parse_exp_in_context.
(parse_exp_in_context): Rename to ...
(parse_exp_in_context_1): ... this.
(parse_exp_in_context): Reimplement, with const hack from
parse_exp_1.
(parse_expression_for_completion): Make "string" parameter const.
* printcmd.c (decode_format): Make "string_ptr" parameter pointer
to pointer to const char. Adjust.
(print_command_1): Make "exp" parameter const.
(output_command): Rename to ...
(output_command_const): ... this. Make "exp" parameter const.
(output_command): Reimplement.
(x_command): Adjust.
(display_command): Rename "exp" parameter to "arg". New "exp"
local, const version of "arg".
* python/py-auto-load.c (gdbpy_initialize_auto_load): Make
"cmd_name" local const.
* python/py-cmd.c (cmdpy_destroyer): Cast const away in xfree
call.
(cmdpy_completer): Make "text" and "word" parameters const.
(gdbpy_parse_command_name): Make "prefix_text2" local const.
* python/py-param.c (add_setshow_generic): Make "tmp_name" local
const.
* remote.c (_initialize_remote): Make "cmd_name" local const.
* symtab.c (language_search_unquoted_string): Make "text" and "p"
parameters const. Adjust.
(completion_list_add_fields): Make "sym_text", "text" and "word"
parameters const.
(struct add_name_data) <sym_text, text, word>: Make fields const.
(default_make_symbol_completion_list_break_on): Make "text" and
"word" parameters const. Adjust locals.
(default_make_symbol_completion_list)
(make_symbol_completion_list, make_symbol_completion_type)
(make_symbol_completion_list_fn): Make "text" and "word"
parameters const.
(make_file_symbol_completion_list): Make "text", "word" and
"srcfile" parameters const. Adjust locals.
(add_filename_to_list): Make "text" and "word" parameters const.
(struct add_partial_filename_data) <text, word>: Make fields
const.
(make_source_files_completion_list): Make "text" and "word"
parameters const.
* symtab.h (default_make_symbol_completion_list_break_on)
(default_make_symbol_completion_list, make_symbol_completion_list)
(make_symbol_completion_type enum type_code)
(make_symbol_completion_list_fn make_file_symbol_completion_list)
(make_source_files_completion_list): Change prototype.
* top.c (execute_command): Adjust to pass pointer to pointer to
const char to lookup_cmd, and to deprecated_cmd_warning prototype
change.
(set_verbose): Make "cmdname" local const.
* tracepoint.c (decode_agent_options): Make "exp" parameter const,
and adjust.
(validate_actionline): Make "line" parameter a pointer to const
char, and adjust.
(encode_actions_1): Make "action_exp" local const, and adjust.
(encode_actions): Adjust.
(replace_comma): Delete.
(trace_dump_actions): Make "action_exp" and "next_comma" locals
const, and adjust. Don't frob the action string while splitting
it at commas. Instead, make a copy of each split substring in
turn.
(trace_dump_command): Adjust to validate_actionline prototype
change.
* tracepoint.h (decode_agent_options, decode_agent_options)
(encode_actions, validate_actionline): Change prototypes.
* valprint.h (output_command): Delete declaration.
(output_command_const): Declare.
* value.c (function_destroyer): Cast const away in xfree call.
2013-03-13 18:34:55 +00:00
|
|
|
|
char *prefix_text;
|
|
|
|
|
const char *prefix_text2;
|
2009-02-06 21:33:59 +00:00
|
|
|
|
char *result;
|
|
|
|
|
|
|
|
|
|
/* Skip trailing whitespace. */
|
2011-09-08 19:51:27 +00:00
|
|
|
|
for (i = len - 1; i >= 0 && (name[i] == ' ' || name[i] == '\t'); --i)
|
2009-02-06 21:33:59 +00:00
|
|
|
|
;
|
|
|
|
|
if (i < 0)
|
|
|
|
|
{
|
2010-04-14 13:18:55 +00:00
|
|
|
|
PyErr_SetString (PyExc_RuntimeError, _("No command name found."));
|
2009-02-06 21:33:59 +00:00
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
lastchar = i;
|
|
|
|
|
|
|
|
|
|
/* Find first character of the final word. */
|
2011-09-08 19:51:27 +00:00
|
|
|
|
for (; i > 0 && (isalnum (name[i - 1])
|
|
|
|
|
|| name[i - 1] == '-'
|
|
|
|
|
|| name[i - 1] == '_');
|
2009-02-06 21:33:59 +00:00
|
|
|
|
--i)
|
|
|
|
|
;
|
2015-09-25 18:08:06 +00:00
|
|
|
|
result = (char *) xmalloc (lastchar - i + 2);
|
2011-09-08 19:51:27 +00:00
|
|
|
|
memcpy (result, &name[i], lastchar - i + 1);
|
2009-02-06 21:33:59 +00:00
|
|
|
|
result[lastchar - i + 1] = '\0';
|
|
|
|
|
|
|
|
|
|
/* Skip whitespace again. */
|
2011-09-08 19:51:27 +00:00
|
|
|
|
for (--i; i >= 0 && (name[i] == ' ' || name[i] == '\t'); --i)
|
2009-02-06 21:33:59 +00:00
|
|
|
|
;
|
|
|
|
|
if (i < 0)
|
|
|
|
|
{
|
2010-04-29 15:45:57 +00:00
|
|
|
|
*base_list = start_list;
|
2009-02-06 21:33:59 +00:00
|
|
|
|
return result;
|
|
|
|
|
}
|
|
|
|
|
|
2015-09-25 18:08:06 +00:00
|
|
|
|
prefix_text = (char *) xmalloc (i + 2);
|
2011-09-08 19:51:27 +00:00
|
|
|
|
memcpy (prefix_text, name, i + 1);
|
2009-02-06 21:33:59 +00:00
|
|
|
|
prefix_text[i + 1] = '\0';
|
|
|
|
|
|
2011-09-08 19:51:27 +00:00
|
|
|
|
prefix_text2 = prefix_text;
|
|
|
|
|
elt = lookup_cmd_1 (&prefix_text2, *start_list, NULL, 1);
|
2014-09-09 03:47:57 +00:00
|
|
|
|
if (elt == NULL || elt == CMD_LIST_AMBIGUOUS)
|
2009-02-06 21:33:59 +00:00
|
|
|
|
{
|
2010-04-14 13:18:55 +00:00
|
|
|
|
PyErr_Format (PyExc_RuntimeError, _("Could not find command prefix %s."),
|
2009-02-06 21:33:59 +00:00
|
|
|
|
prefix_text);
|
|
|
|
|
xfree (prefix_text);
|
|
|
|
|
xfree (result);
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (elt->prefixlist)
|
|
|
|
|
{
|
|
|
|
|
xfree (prefix_text);
|
|
|
|
|
*base_list = elt->prefixlist;
|
|
|
|
|
return result;
|
|
|
|
|
}
|
|
|
|
|
|
2010-04-14 13:18:55 +00:00
|
|
|
|
PyErr_Format (PyExc_RuntimeError, _("'%s' is not a prefix command."),
|
2009-02-06 21:33:59 +00:00
|
|
|
|
prefix_text);
|
|
|
|
|
xfree (prefix_text);
|
|
|
|
|
xfree (result);
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Object initializer; sets up gdb-side structures for command.
|
|
|
|
|
|
2009-03-21 03:13:02 +00:00
|
|
|
|
Use: __init__(NAME, COMMAND_CLASS [, COMPLETER_CLASS][, PREFIX]]).
|
2009-02-06 21:33:59 +00:00
|
|
|
|
|
|
|
|
|
NAME is the name of the command. It may consist of multiple words,
|
|
|
|
|
in which case the final word is the name of the new command, and
|
|
|
|
|
earlier words must be prefix commands.
|
|
|
|
|
|
2009-03-21 03:13:02 +00:00
|
|
|
|
COMMAND_CLASS is the kind of command. It should be one of the COMMAND_*
|
2009-02-06 21:33:59 +00:00
|
|
|
|
constants defined in the gdb module.
|
|
|
|
|
|
2009-03-21 03:13:02 +00:00
|
|
|
|
COMPLETER_CLASS is the kind of completer. If not given, the
|
2009-02-06 21:33:59 +00:00
|
|
|
|
"complete" method will be used. Otherwise, it should be one of the
|
|
|
|
|
COMPLETE_* constants defined in the gdb module.
|
|
|
|
|
|
|
|
|
|
If PREFIX is True, then this command is a prefix command.
|
|
|
|
|
|
|
|
|
|
The documentation for the command is taken from the doc string for
|
2011-09-08 19:51:27 +00:00
|
|
|
|
the python class. */
|
|
|
|
|
|
2009-02-06 21:33:59 +00:00
|
|
|
|
static int
|
2009-03-21 03:13:02 +00:00
|
|
|
|
cmdpy_init (PyObject *self, PyObject *args, PyObject *kw)
|
2009-02-06 21:33:59 +00:00
|
|
|
|
{
|
|
|
|
|
cmdpy_object *obj = (cmdpy_object *) self;
|
2011-06-24 19:47:37 +00:00
|
|
|
|
const char *name;
|
2009-02-06 21:33:59 +00:00
|
|
|
|
int cmdtype;
|
|
|
|
|
int completetype = -1;
|
|
|
|
|
char *docstring = NULL;
|
|
|
|
|
struct cmd_list_element **cmd_list;
|
|
|
|
|
char *cmd_name, *pfx_name;
|
2009-03-21 03:13:02 +00:00
|
|
|
|
static char *keywords[] = { "name", "command_class", "completer_class",
|
|
|
|
|
"prefix", NULL };
|
2009-02-06 21:33:59 +00:00
|
|
|
|
PyObject *is_prefix = NULL;
|
|
|
|
|
int cmp;
|
|
|
|
|
|
|
|
|
|
if (obj->command)
|
|
|
|
|
{
|
|
|
|
|
/* Note: this is apparently not documented in Python. We return
|
|
|
|
|
0 for success, -1 for failure. */
|
|
|
|
|
PyErr_Format (PyExc_RuntimeError,
|
2010-04-14 13:18:55 +00:00
|
|
|
|
_("Command object already initialized."));
|
2009-02-06 21:33:59 +00:00
|
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
|
2011-01-06 00:57:05 +00:00
|
|
|
|
if (! PyArg_ParseTupleAndKeywords (args, kw, "si|iO",
|
|
|
|
|
keywords, &name, &cmdtype,
|
2009-02-06 21:33:59 +00:00
|
|
|
|
&completetype, &is_prefix))
|
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
|
|
if (cmdtype != no_class && cmdtype != class_run
|
|
|
|
|
&& cmdtype != class_vars && cmdtype != class_stack
|
|
|
|
|
&& cmdtype != class_files && cmdtype != class_support
|
|
|
|
|
&& cmdtype != class_info && cmdtype != class_breakpoint
|
|
|
|
|
&& cmdtype != class_trace && cmdtype != class_obscure
|
2012-03-01 19:30:25 +00:00
|
|
|
|
&& cmdtype != class_maintenance && cmdtype != class_user)
|
2009-02-06 21:33:59 +00:00
|
|
|
|
{
|
2010-04-14 13:18:55 +00:00
|
|
|
|
PyErr_Format (PyExc_RuntimeError, _("Invalid command class argument."));
|
2009-02-06 21:33:59 +00:00
|
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (completetype < -1 || completetype >= (int) N_COMPLETERS)
|
|
|
|
|
{
|
2011-01-06 00:57:05 +00:00
|
|
|
|
PyErr_Format (PyExc_RuntimeError,
|
|
|
|
|
_("Invalid completion type argument."));
|
2009-02-06 21:33:59 +00:00
|
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
|
2011-09-08 19:51:27 +00:00
|
|
|
|
cmd_name = gdbpy_parse_command_name (name, &cmd_list, &cmdlist);
|
2009-02-06 21:33:59 +00:00
|
|
|
|
if (! cmd_name)
|
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
|
|
pfx_name = NULL;
|
2013-11-29 20:00:47 +00:00
|
|
|
|
if (is_prefix != NULL)
|
2009-02-06 21:33:59 +00:00
|
|
|
|
{
|
|
|
|
|
cmp = PyObject_IsTrue (is_prefix);
|
|
|
|
|
if (cmp == 1)
|
|
|
|
|
{
|
|
|
|
|
int i, out;
|
2013-11-29 20:00:47 +00:00
|
|
|
|
|
2009-02-06 21:33:59 +00:00
|
|
|
|
/* Make a normalized form of the command name. */
|
2015-09-25 18:08:06 +00:00
|
|
|
|
pfx_name = (char *) xmalloc (strlen (name) + 2);
|
2013-11-29 20:00:47 +00:00
|
|
|
|
|
2009-02-06 21:33:59 +00:00
|
|
|
|
i = 0;
|
|
|
|
|
out = 0;
|
|
|
|
|
while (name[i])
|
|
|
|
|
{
|
|
|
|
|
/* Skip whitespace. */
|
|
|
|
|
while (name[i] == ' ' || name[i] == '\t')
|
|
|
|
|
++i;
|
|
|
|
|
/* Copy non-whitespace characters. */
|
|
|
|
|
while (name[i] && name[i] != ' ' && name[i] != '\t')
|
|
|
|
|
pfx_name[out++] = name[i++];
|
|
|
|
|
/* Add a single space after each word -- including the final
|
|
|
|
|
word. */
|
|
|
|
|
pfx_name[out++] = ' ';
|
|
|
|
|
}
|
|
|
|
|
pfx_name[out] = '\0';
|
|
|
|
|
}
|
|
|
|
|
else if (cmp < 0)
|
2011-02-28 18:55:22 +00:00
|
|
|
|
{
|
|
|
|
|
xfree (cmd_name);
|
2009-02-06 21:33:59 +00:00
|
|
|
|
return -1;
|
2011-02-28 18:55:22 +00:00
|
|
|
|
}
|
2009-02-06 21:33:59 +00:00
|
|
|
|
}
|
|
|
|
|
if (PyObject_HasAttr (self, gdbpy_doc_cst))
|
|
|
|
|
{
|
|
|
|
|
PyObject *ds_obj = PyObject_GetAttr (self, gdbpy_doc_cst);
|
2010-05-17 21:23:25 +00:00
|
|
|
|
|
2009-02-06 21:33:59 +00:00
|
|
|
|
if (ds_obj && gdbpy_is_string (ds_obj))
|
2010-10-13 13:24:40 +00:00
|
|
|
|
{
|
|
|
|
|
docstring = python_string_to_host_string (ds_obj);
|
|
|
|
|
if (docstring == NULL)
|
|
|
|
|
{
|
|
|
|
|
xfree (cmd_name);
|
|
|
|
|
xfree (pfx_name);
|
2013-05-20 20:20:48 +00:00
|
|
|
|
Py_DECREF (ds_obj);
|
2010-10-13 13:24:40 +00:00
|
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
}
|
2013-05-20 20:20:48 +00:00
|
|
|
|
|
|
|
|
|
Py_XDECREF (ds_obj);
|
2009-02-06 21:33:59 +00:00
|
|
|
|
}
|
|
|
|
|
if (! docstring)
|
|
|
|
|
docstring = xstrdup (_("This command is not documented."));
|
|
|
|
|
|
|
|
|
|
Py_INCREF (self);
|
|
|
|
|
|
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 15:14:14 +00:00
|
|
|
|
TRY
|
2009-02-06 21:33:59 +00:00
|
|
|
|
{
|
|
|
|
|
struct cmd_list_element *cmd;
|
|
|
|
|
|
|
|
|
|
if (pfx_name)
|
|
|
|
|
{
|
|
|
|
|
int allow_unknown;
|
|
|
|
|
|
|
|
|
|
/* If we have our own "invoke" method, then allow unknown
|
|
|
|
|
sub-commands. */
|
|
|
|
|
allow_unknown = PyObject_HasAttr (self, invoke_cst);
|
|
|
|
|
cmd = add_prefix_cmd (cmd_name, (enum command_class) cmdtype,
|
|
|
|
|
NULL, docstring, &obj->sub_list,
|
|
|
|
|
pfx_name, allow_unknown, cmd_list);
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
cmd = add_cmd (cmd_name, (enum command_class) cmdtype, NULL,
|
|
|
|
|
docstring, cmd_list);
|
|
|
|
|
|
|
|
|
|
/* There appears to be no API to set this. */
|
|
|
|
|
cmd->func = cmdpy_function;
|
|
|
|
|
cmd->destroyer = cmdpy_destroyer;
|
|
|
|
|
|
|
|
|
|
obj->command = cmd;
|
|
|
|
|
set_cmd_context (cmd, self);
|
|
|
|
|
set_cmd_completer (cmd, ((completetype == -1) ? cmdpy_completer
|
|
|
|
|
: completers[completetype].completer));
|
PR python/16699: GDB Python command completion with overriden complete vs. completer class
This PR came from a Red Hat bug that was filed recently. I checked and
it still exists on HEAD, so here's a proposed fix. Although this is
marked as a Python backend bug, this is really about the completion
mechanism used by GDB. Since this code reminds me of my first attempt
to make a good noodle, it took me quite some time to fix it in a
non-intrusive way.
The problem is triggered when one registers a completion method inside a
class in a Python script, rather than registering the command using a
completer class directly. For example, consider the following script:
class MyFirstCommand(gdb.Command):
def __init__(self):
gdb.Command.__init__(self,'myfirstcommand',gdb.COMMAND_USER,gdb.COMPLETE_FILENAME)
def invoke(self,argument,from_tty):
raise gdb.GdbError('not implemented')
class MySecondCommand(gdb.Command):
def __init__(self):
gdb.Command.__init__(self,'mysecondcommand',gdb.COMMAND_USER)
def invoke(self,argument,from_tty):
raise gdb.GdbError('not implemented')
def complete(self,text,word):
return gdb.COMPLETE_FILENAME
MyFirstCommand ()
MySecondCommand ()
When one loads this into GDB and tries to complete filenames for both
myfirstcommand and mysecondcommand, she gets:
(gdb) myfirstcommand /hom<TAB>
(gdb) myfirstcommand /home/
^
...
(gdb) mysecondcommand /hom<TAB>
(gdb) mysecondcommand /home
^
(The "^" marks the final position of the cursor after the TAB).
So we see that myfirstcommand honors the COMPLETE_FILENAME class (as
specified in the command creation), but mysecondcommand does not. After
some investigation, I found that the problem lies with the set of word
break characters that is used for each case. The set should be the same
for both commands, but it is not.
During the process of deciding which type of completion should be used,
the code in gdb/completer.c:complete_line_internal analyses the command
that requested the completion and tries to determine the type of
completion wanted by checking which completion function will be called
(e.g., filename_completer for filenames, location_completer for
locations, etc.).
This all works fine for myfirstcommand, because immediately after the
command registration the Python backend already sets its completion
function to filename_completer (which then causes the
complete_line_internal function to choose the right set of word break
chars). However, for mysecondcommand, this decision is postponed to
when the completer function is evaluated, and the Python backend uses an
internal completer (called cmdpy_completer). complete_line_internal
doesn't know about this internal completer, and can't choose the right
set of word break chars in time, which then leads to a bad decision when
completing the "/hom" word.
So, after a few attempts, I decided to create another callback in
"struct cmd_list_element" that will be responsible for handling the case
when there is an unknown completer function for complete_line_internal
to work with. So far, only the Python backend uses this callback, and
only when the user provides a completer method instead of registering
the command directly with a completer class. I think this is the best
option because it not very intrusive (all the other commands will still
work normally), but especially because the whole completion code is so
messy that it would be hard to fix this without having to redesign
things.
I have regtested this on Fedora 18 x86_64, without regressions. I also
included a testcase.
gdb/ChangeLog:
2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* cli/cli-decode.c (set_cmd_completer_handle_brkchars): New
function.
(add_cmd): Set "completer_handle_brkchars" to NULL.
* cli/cli-decode.h (struct cmd_list_element)
<completer_handle_brkchars>: New field.
* command.h (completer_ftype_void): New typedef.
(set_cmd_completer_handle_brkchars): New prototype.
* completer.c (set_gdb_completion_word_break_characters): New
function.
(complete_line_internal): Call "completer_handle_brkchars"
callback from command.
* completer.h: Include "command.h".
(set_gdb_completion_word_break_characters): New prototype.
* python/py-cmd.c (cmdpy_completer_helper): New function.
(cmdpy_completer_handle_brkchars): New function.
(cmdpy_completer): Adjust to use cmdpy_completer_helper.
(cmdpy_init): Set completer_handle_brkchars to
cmdpy_completer_handle_brkchars.
gdb/testsuite/ChangeLog:
2014-09-03 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* gdb.python/py-completion.exp: New file.
* gdb.python/py-completion.py: Likewise.
2014-09-03 20:30:28 +00:00
|
|
|
|
if (completetype == -1)
|
|
|
|
|
set_cmd_completer_handle_brkchars (cmd,
|
|
|
|
|
cmdpy_completer_handle_brkchars);
|
2009-02-06 21:33:59 +00:00
|
|
|
|
}
|
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 15:14:14 +00:00
|
|
|
|
CATCH (except, RETURN_MASK_ALL)
|
2009-02-06 21:33:59 +00:00
|
|
|
|
{
|
|
|
|
|
xfree (cmd_name);
|
|
|
|
|
xfree (docstring);
|
|
|
|
|
xfree (pfx_name);
|
|
|
|
|
Py_DECREF (self);
|
|
|
|
|
PyErr_Format (except.reason == RETURN_QUIT
|
|
|
|
|
? PyExc_KeyboardInterrupt : PyExc_RuntimeError,
|
|
|
|
|
"%s", except.message);
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
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 15:14:14 +00:00
|
|
|
|
END_CATCH
|
|
|
|
|
|
2009-02-06 21:33:59 +00:00
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* Initialize the 'commands' code. */
|
2011-09-08 19:51:27 +00:00
|
|
|
|
|
* 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 20:28:52 +00:00
|
|
|
|
int
|
2009-02-06 21:33:59 +00:00
|
|
|
|
gdbpy_initialize_commands (void)
|
|
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
|
2011-08-05 14:24:10 +00:00
|
|
|
|
cmdpy_object_type.tp_new = PyType_GenericNew;
|
2009-02-06 21:33:59 +00:00
|
|
|
|
if (PyType_Ready (&cmdpy_object_type) < 0)
|
* 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 20:28:52 +00:00
|
|
|
|
return -1;
|
2009-02-06 21:33:59 +00:00
|
|
|
|
|
|
|
|
|
/* Note: alias and user are special; pseudo appears to be unused,
|
Remove --xdb
Pedro Alves:
The commands that enables aren't even documented in the manual.
Judging from that, I assume that only wdb users would ever really
be using the --xdb switch.
I think it's time to drop "support" for the --xdb switch too. I
looked through the commands that that exposes, the only that looked
potentially interesting was "go", but then it's just an alias
for "tbreak+jump", which can easily be done with "define go...end".
I'd rather free up the "go" name for something potentially
more interesting (either run control, or maybe even unrelated,
e.g., for golang).
gdb/ChangeLog
2015-04-11 Jan Kratochvil <jan.kratochvil@redhat.com>
* NEWS (Changes since GDB 7.9): Add removed -xdb.
* breakpoint.c (command_line_is_silent): Remove xdb_commands
conditional.
(_initialize_breakpoint): Remove xdb_commands for bc, ab, sb, db, ba
and lb.
* cli/cli-cmds.c (_initialize_cli_cmds): Remove xdb_commands for v and
va.
* cli/cli-decode.c (find_command_name_length): Remove xdb_commands
conditional.
* defs.h (xdb_commands): Remove declaration.
* f-valprint.c (_initialize_f_valprint): Remove xdb_commands for lc.
* guile/scm-cmd.c (command_classes): Remove xdb from comment.
* infcmd.c (run_no_args_command, go_command): Remove.
(_initialize_infcmd): Remove xdb_commands for S, go, g, R and lr.
* infrun.c (xdb_handle_command): Remove.
(_initialize_infrun): Remove xdb_commands for lz and z.
* main.c (xdb_commands): Remove variable.
(captured_main): Remove "xdb" from long_options.
(print_gdb_help): Remove --xdb from help.
* python/py-cmd.c (gdbpy_initialize_commands): Remove xdb from comment.
* source.c (_initialize_source): Remove xdb_commands for D, ld, / and ?.
* stack.c (backtrace_full_command, args_plus_locals_info)
(current_frame_command): Remove.
(_initialize_stack): Remove xdb_commands for t, T and l.
* symtab.c (_initialize_symtab): Remove xdb_commands for lf and lg.
* thread.c (_initialize_thread): Remove xdb_commands condition.
* tui/tui-layout.c (tui_toggle_layout_command)
(tui_toggle_split_layout_command, tui_handle_xdb_layout): Remove.
(_initialize_tui_layout): Remove xdb_commands for td and ts.
* tui/tui-regs.c (tui_scroll_regs_forward_command)
(tui_scroll_regs_backward_command): Remove.
(_initialize_tui_regs): Remove xdb_commands for fr, gr, sr, +r and -r.
* tui/tui-win.c (tui_xdb_set_win_height_command): Remove.
(_initialize_tui_win): Remove xdb_commands for U and w.
* utils.c (pagination_on_command, pagination_off_command): Remove.
(initialize_utils): Remove xdb_commands for am and sm.
gdb/doc/ChangeLog
2015-04-11 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.texinfo (Mode Options): Remove -xdb.
2015-04-11 17:49:03 +00:00
|
|
|
|
and there is no reason to expose tui, I think. */
|
2009-02-06 21:33:59 +00:00
|
|
|
|
if (PyModule_AddIntConstant (gdb_module, "COMMAND_NONE", no_class) < 0
|
|
|
|
|
|| PyModule_AddIntConstant (gdb_module, "COMMAND_RUNNING", class_run) < 0
|
|
|
|
|
|| PyModule_AddIntConstant (gdb_module, "COMMAND_DATA", class_vars) < 0
|
|
|
|
|
|| PyModule_AddIntConstant (gdb_module, "COMMAND_STACK", class_stack) < 0
|
|
|
|
|
|| PyModule_AddIntConstant (gdb_module, "COMMAND_FILES", class_files) < 0
|
|
|
|
|
|| PyModule_AddIntConstant (gdb_module, "COMMAND_SUPPORT",
|
|
|
|
|
class_support) < 0
|
|
|
|
|
|| PyModule_AddIntConstant (gdb_module, "COMMAND_STATUS", class_info) < 0
|
|
|
|
|
|| PyModule_AddIntConstant (gdb_module, "COMMAND_BREAKPOINTS",
|
|
|
|
|
class_breakpoint) < 0
|
|
|
|
|
|| PyModule_AddIntConstant (gdb_module, "COMMAND_TRACEPOINTS",
|
|
|
|
|
class_trace) < 0
|
|
|
|
|
|| PyModule_AddIntConstant (gdb_module, "COMMAND_OBSCURE",
|
|
|
|
|
class_obscure) < 0
|
|
|
|
|
|| PyModule_AddIntConstant (gdb_module, "COMMAND_MAINTENANCE",
|
2012-03-01 19:30:25 +00:00
|
|
|
|
class_maintenance) < 0
|
|
|
|
|
|| PyModule_AddIntConstant (gdb_module, "COMMAND_USER", class_user) < 0)
|
* 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 20:28:52 +00:00
|
|
|
|
return -1;
|
2009-02-06 21:33:59 +00:00
|
|
|
|
|
|
|
|
|
for (i = 0; i < N_COMPLETERS; ++i)
|
|
|
|
|
{
|
|
|
|
|
if (PyModule_AddIntConstant (gdb_module, completers[i].name, i) < 0)
|
* 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 20:28:52 +00:00
|
|
|
|
return -1;
|
2009-02-06 21:33:59 +00:00
|
|
|
|
}
|
|
|
|
|
|
2013-05-20 20:36:19 +00:00
|
|
|
|
if (gdb_pymodule_addobject (gdb_module, "Command",
|
|
|
|
|
(PyObject *) &cmdpy_object_type) < 0)
|
* 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 20:28:52 +00:00
|
|
|
|
return -1;
|
2009-02-06 21:33:59 +00:00
|
|
|
|
|
|
|
|
|
invoke_cst = PyString_FromString ("invoke");
|
* 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 20:28:52 +00:00
|
|
|
|
if (invoke_cst == NULL)
|
|
|
|
|
return -1;
|
2009-02-06 21:33:59 +00:00
|
|
|
|
complete_cst = PyString_FromString ("complete");
|
* 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 20:28:52 +00:00
|
|
|
|
if (complete_cst == NULL)
|
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
|
|
return 0;
|
2009-02-06 21:33:59 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
static PyMethodDef cmdpy_object_methods[] =
|
|
|
|
|
{
|
|
|
|
|
{ "dont_repeat", cmdpy_dont_repeat, METH_NOARGS,
|
|
|
|
|
"Prevent command repetition when user enters empty line." },
|
|
|
|
|
|
|
|
|
|
{ 0 }
|
|
|
|
|
};
|
|
|
|
|
|
Fix redefinition errors in C++ mode
In C, we can forward declare static structure instances. That doesn't
work in C++ though. C++ treats these as definitions. So then the
compiler complains about symbol redefinition, like:
src/gdb/elfread.c:1569:29: error: redefinition of ‘const sym_fns elf_sym_fns_lazy_psyms’
src/gdb/elfread.c:53:29: error: ‘const sym_fns elf_sym_fns_lazy_psyms’ previously declared here
The intent of static here is naturally to avoid making these objects
visible outside the compilation unit. The equivalent in C++ would be
to instead define the objects in the anonymous namespace. But given
that it's desirable to leave the codebase compiling as both C and C++
for a while, this just makes the objects extern.
(base_breakpoint_ops is already declared in breakpoint.h, so we can
just remove the forward declare from breakpoint.c)
gdb/ChangeLog:
2015-02-11 Tom Tromey <tromey@redhat.com>
Pedro Alves <palves@redhat.com>
* breakpoint.c (base_breakpoint_ops): Delete.
* dwarf2loc.c (dwarf_expr_ctx_funcs): Make extern.
* elfread.c (elf_sym_fns_gdb_index, elf_sym_fns_lazy_psyms): Make extern.
* guile/guile.c (guile_extension_script_ops, guile_extension_ops): Make extern.
* ppcnbsd-tdep.c (ppcnbsd2_sigtramp): Make extern.
* python/py-arch.c (arch_object_type): Make extern.
* python/py-block.c (block_syms_iterator_object_type): Make extern.
* python/py-bpevent.c (breakpoint_event_object_type): Make extern.
* python/py-cmd.c (cmdpy_object_type): Make extern.
* python/py-continueevent.c (continue_event_object_type)
* python/py-event.h (GDBPY_NEW_EVENT_TYPE): Remove 'qual'
parameter. Update all callers.
* python/py-evtregistry.c (eventregistry_object_type): Make extern.
* python/py-exitedevent.c (exited_event_object_type): Make extern.
* python/py-finishbreakpoint.c (finish_breakpoint_object_type): Make extern.
* python/py-function.c (fnpy_object_type): Make extern.
* python/py-inferior.c (inferior_object_type, membuf_object_type): Make extern.
* python/py-infevents.c (call_pre_event_object_type)
(inferior_call_post_event_object_type).
(memory_changed_event_object_type): Make extern.
* python/py-infthread.c (thread_object_type): Make extern.
* python/py-lazy-string.c (lazy_string_object_type): Make extern.
* python/py-linetable.c (linetable_entry_object_type)
(linetable_object_type, ltpy_iterator_object_type): Make extern.
* python/py-newobjfileevent.c (new_objfile_event_object_type)
(clear_objfiles_event_object_type): Make extern.
* python/py-objfile.c (objfile_object_type): Make extern.
* python/py-param.c (parmpy_object_type): Make extern.
* python/py-progspace.c (pspace_object_type): Make extern.
* python/py-signalevent.c (signal_event_object_type): Make extern.
* python/py-symtab.c (symtab_object_type, sal_object_type): Make extern.
* python/py-type.c (type_object_type, field_object_type)
(type_iterator_object_type): Make extern.
* python/python.c (python_extension_script_ops)
(python_extension_ops): Make extern.
* stap-probe.c (stap_probe_ops): Make extern.
2015-02-11 11:20:21 +00:00
|
|
|
|
PyTypeObject cmdpy_object_type =
|
2009-02-06 21:33:59 +00:00
|
|
|
|
{
|
2012-12-12 16:47:30 +00:00
|
|
|
|
PyVarObject_HEAD_INIT (NULL, 0)
|
2009-02-06 21:33:59 +00:00
|
|
|
|
"gdb.Command", /*tp_name*/
|
|
|
|
|
sizeof (cmdpy_object), /*tp_basicsize*/
|
|
|
|
|
0, /*tp_itemsize*/
|
|
|
|
|
0, /*tp_dealloc*/
|
|
|
|
|
0, /*tp_print*/
|
|
|
|
|
0, /*tp_getattr*/
|
|
|
|
|
0, /*tp_setattr*/
|
|
|
|
|
0, /*tp_compare*/
|
|
|
|
|
0, /*tp_repr*/
|
|
|
|
|
0, /*tp_as_number*/
|
|
|
|
|
0, /*tp_as_sequence*/
|
|
|
|
|
0, /*tp_as_mapping*/
|
|
|
|
|
0, /*tp_hash */
|
|
|
|
|
0, /*tp_call*/
|
|
|
|
|
0, /*tp_str*/
|
|
|
|
|
0, /*tp_getattro*/
|
|
|
|
|
0, /*tp_setattro*/
|
|
|
|
|
0, /*tp_as_buffer*/
|
|
|
|
|
Py_TPFLAGS_DEFAULT | Py_TPFLAGS_BASETYPE, /*tp_flags*/
|
|
|
|
|
"GDB command object", /* tp_doc */
|
|
|
|
|
0, /* tp_traverse */
|
|
|
|
|
0, /* tp_clear */
|
|
|
|
|
0, /* tp_richcompare */
|
|
|
|
|
0, /* tp_weaklistoffset */
|
|
|
|
|
0, /* tp_iter */
|
|
|
|
|
0, /* tp_iternext */
|
|
|
|
|
cmdpy_object_methods, /* tp_methods */
|
|
|
|
|
0, /* tp_members */
|
|
|
|
|
0, /* tp_getset */
|
|
|
|
|
0, /* tp_base */
|
|
|
|
|
0, /* tp_dict */
|
|
|
|
|
0, /* tp_descr_get */
|
|
|
|
|
0, /* tp_descr_set */
|
|
|
|
|
0, /* tp_dictoffset */
|
|
|
|
|
cmdpy_init, /* tp_init */
|
|
|
|
|
0, /* tp_alloc */
|
|
|
|
|
};
|
2010-05-25 15:27:17 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* Utility to build a buildargv-like result from ARGS.
|
|
|
|
|
This intentionally parses arguments the way libiberty/argv.c:buildargv
|
|
|
|
|
does. It splits up arguments in a reasonable way, and we want a standard
|
|
|
|
|
way of parsing arguments. Several gdb commands use buildargv to parse their
|
|
|
|
|
arguments. Plus we want to be able to write compatible python
|
|
|
|
|
implementations of gdb commands. */
|
|
|
|
|
|
|
|
|
|
PyObject *
|
|
|
|
|
gdbpy_string_to_argv (PyObject *self, PyObject *args)
|
|
|
|
|
{
|
|
|
|
|
PyObject *py_argv;
|
2011-06-24 19:47:37 +00:00
|
|
|
|
const char *input;
|
2010-05-25 15:27:17 +00:00
|
|
|
|
|
|
|
|
|
if (!PyArg_ParseTuple (args, "s", &input))
|
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
py_argv = PyList_New (0);
|
2013-05-20 20:14:51 +00:00
|
|
|
|
if (py_argv == NULL)
|
|
|
|
|
return NULL;
|
2010-05-25 15:27:17 +00:00
|
|
|
|
|
|
|
|
|
/* buildargv uses NULL to represent an empty argument list, but we can't use
|
|
|
|
|
that in Python. Instead, if ARGS is "" then return an empty list.
|
|
|
|
|
This undoes the NULL -> "" conversion that cmdpy_function does. */
|
|
|
|
|
|
|
|
|
|
if (*input != '\0')
|
|
|
|
|
{
|
|
|
|
|
char **c_argv = gdb_buildargv (input);
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
for (i = 0; c_argv[i] != NULL; ++i)
|
|
|
|
|
{
|
|
|
|
|
PyObject *argp = PyString_FromString (c_argv[i]);
|
|
|
|
|
|
|
|
|
|
if (argp == NULL
|
|
|
|
|
|| PyList_Append (py_argv, argp) < 0)
|
|
|
|
|
{
|
2011-09-15 18:33:15 +00:00
|
|
|
|
Py_XDECREF (argp);
|
2010-05-25 15:27:17 +00:00
|
|
|
|
Py_DECREF (py_argv);
|
|
|
|
|
freeargv (c_argv);
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
2011-09-15 18:33:15 +00:00
|
|
|
|
Py_DECREF (argp);
|
2010-05-25 15:27:17 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
freeargv (c_argv);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return py_argv;
|
|
|
|
|
}
|