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

1026 lines
28 KiB
C
Raw Permalink Normal View History

/* GDB parameters implemented in Python
Copyright (C) 2008-2026 Free Software Foundation, Inc.
This file is part of GDB.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>. */
#include "value.h"
#include "python-internal.h"
#include "charset.h"
#include "cli/cli-cmds.h"
#include "cli/cli-decode.h"
#include "completer.h"
#include "language.h"
#include "arch-utils.h"
#include "py-color.h"
GDB: Allow arbitrary keywords in integer set commands Rather than just `unlimited' allow the integer set commands (or command options) to define arbitrary keywords for the user to use, removing hardcoded arrangements for the `unlimited' keyword. Remove the confusingly named `var_zinteger', `var_zuinteger' and `var_zuinteger_unlimited' `set'/`show' command variable types redefining them in terms of `var_uinteger', `var_integer' and `var_pinteger', which have the range of [0;UINT_MAX], [INT_MIN;INT_MAX], and [0;INT_MAX] each. Following existing practice `var_pinteger' allows extra negative values to be used, however unlike `var_zuinteger_unlimited' any number of such values can be defined rather than just `-1'. The "p" in `var_pinteger' stands for "positive", for the lack of a more appropriate unambiguous letter, even though 0 obviously is not positive; "n" would be confusing as to whether it stands for "non-negative" or "negative". Add a new structure, `literal_def', the entries of which define extra keywords allowed for a command and numerical values they correspond to. Those values are not verified against the basic range supported by the underlying variable type, allowing extra values to be allowed outside that range, which may or may not be individually made visible to the user. An optional value translation is possible with the structure to follow the existing practice for some commands where user-entered 0 is internally translated to UINT_MAX or INT_MAX. Such translation can now be arbitrary. Literals defined by this structure are automatically used for completion as necessary. So for example: const literal_def integer_unlimited_literals[] = { { "unlimited", INT_MAX, 0 }, { nullptr } }; defines an extra `unlimited' keyword and a user-visible 0 value, both of which get translated to INT_MAX for the setting to be used with. Similarly: const literal_def zuinteger_unlimited_literals[] = { { "unlimited", -1, -1 }, { nullptr } }; defines the same keyword and a corresponding user-visible -1 value that is used for the requested setting. If the last member were omitted (or set to `{}') here, then only the keyword would be allowed for the user to enter and while -1 would still be used internally trying to enter it as a part of a command would result in an "integer -1 out of range" error. Use said error message in all cases (citing the invalid value requested) replacing "only -1 is allowed to set as unlimited" previously used for `var_zuinteger_unlimited' settings only rather than propagating it to `var_pinteger' type. It could only be used for the specific case where a single extra `unlimited' keyword was defined standing for -1 and the use of numeric equivalents is discouraged anyway as it is for historical reasons only that they expose GDB internals, confusingly different across variable types. Similarly update the "must be >= -1" Guile error message. Redefine Guile and Python parameter types in terms of the new variable types and interpret extra keywords as Scheme keywords and Python strings used to communicate corresponding parameter values. Do not add a new PARAM_INTEGER Guile parameter type, however do handle the `var_integer' variable type now, permitting existing parameters defined by GDB proper, such as `listsize', to be accessed from Scheme code. With these changes in place it should be trivial for a Scheme or Python programmer to expand the syntax of the `make-parameter' command and the `gdb.Parameter' class initializer to have arbitrary extra literals along with their internal representation supplied. Update the testsuite accordingly. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-19 21:15:56 +00:00
/* Python parameter types as in PARM_CONSTANTS below. */
enum py_param_types
GDB: Allow arbitrary keywords in integer set commands Rather than just `unlimited' allow the integer set commands (or command options) to define arbitrary keywords for the user to use, removing hardcoded arrangements for the `unlimited' keyword. Remove the confusingly named `var_zinteger', `var_zuinteger' and `var_zuinteger_unlimited' `set'/`show' command variable types redefining them in terms of `var_uinteger', `var_integer' and `var_pinteger', which have the range of [0;UINT_MAX], [INT_MIN;INT_MAX], and [0;INT_MAX] each. Following existing practice `var_pinteger' allows extra negative values to be used, however unlike `var_zuinteger_unlimited' any number of such values can be defined rather than just `-1'. The "p" in `var_pinteger' stands for "positive", for the lack of a more appropriate unambiguous letter, even though 0 obviously is not positive; "n" would be confusing as to whether it stands for "non-negative" or "negative". Add a new structure, `literal_def', the entries of which define extra keywords allowed for a command and numerical values they correspond to. Those values are not verified against the basic range supported by the underlying variable type, allowing extra values to be allowed outside that range, which may or may not be individually made visible to the user. An optional value translation is possible with the structure to follow the existing practice for some commands where user-entered 0 is internally translated to UINT_MAX or INT_MAX. Such translation can now be arbitrary. Literals defined by this structure are automatically used for completion as necessary. So for example: const literal_def integer_unlimited_literals[] = { { "unlimited", INT_MAX, 0 }, { nullptr } }; defines an extra `unlimited' keyword and a user-visible 0 value, both of which get translated to INT_MAX for the setting to be used with. Similarly: const literal_def zuinteger_unlimited_literals[] = { { "unlimited", -1, -1 }, { nullptr } }; defines the same keyword and a corresponding user-visible -1 value that is used for the requested setting. If the last member were omitted (or set to `{}') here, then only the keyword would be allowed for the user to enter and while -1 would still be used internally trying to enter it as a part of a command would result in an "integer -1 out of range" error. Use said error message in all cases (citing the invalid value requested) replacing "only -1 is allowed to set as unlimited" previously used for `var_zuinteger_unlimited' settings only rather than propagating it to `var_pinteger' type. It could only be used for the specific case where a single extra `unlimited' keyword was defined standing for -1 and the use of numeric equivalents is discouraged anyway as it is for historical reasons only that they expose GDB internals, confusingly different across variable types. Similarly update the "must be >= -1" Guile error message. Redefine Guile and Python parameter types in terms of the new variable types and interpret extra keywords as Scheme keywords and Python strings used to communicate corresponding parameter values. Do not add a new PARAM_INTEGER Guile parameter type, however do handle the `var_integer' variable type now, permitting existing parameters defined by GDB proper, such as `listsize', to be accessed from Scheme code. With these changes in place it should be trivial for a Scheme or Python programmer to expand the syntax of the `make-parameter' command and the `gdb.Parameter' class initializer to have arbitrary extra literals along with their internal representation supplied. Update the testsuite accordingly. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-19 21:15:56 +00:00
{
param_boolean,
param_auto_boolean,
param_uinteger,
param_integer,
param_string,
param_string_noescape,
param_optional_filename,
param_filename,
param_zinteger,
param_zuinteger,
param_zuinteger_unlimited,
param_enum,
param_color,
};
GDB: Allow arbitrary keywords in integer set commands Rather than just `unlimited' allow the integer set commands (or command options) to define arbitrary keywords for the user to use, removing hardcoded arrangements for the `unlimited' keyword. Remove the confusingly named `var_zinteger', `var_zuinteger' and `var_zuinteger_unlimited' `set'/`show' command variable types redefining them in terms of `var_uinteger', `var_integer' and `var_pinteger', which have the range of [0;UINT_MAX], [INT_MIN;INT_MAX], and [0;INT_MAX] each. Following existing practice `var_pinteger' allows extra negative values to be used, however unlike `var_zuinteger_unlimited' any number of such values can be defined rather than just `-1'. The "p" in `var_pinteger' stands for "positive", for the lack of a more appropriate unambiguous letter, even though 0 obviously is not positive; "n" would be confusing as to whether it stands for "non-negative" or "negative". Add a new structure, `literal_def', the entries of which define extra keywords allowed for a command and numerical values they correspond to. Those values are not verified against the basic range supported by the underlying variable type, allowing extra values to be allowed outside that range, which may or may not be individually made visible to the user. An optional value translation is possible with the structure to follow the existing practice for some commands where user-entered 0 is internally translated to UINT_MAX or INT_MAX. Such translation can now be arbitrary. Literals defined by this structure are automatically used for completion as necessary. So for example: const literal_def integer_unlimited_literals[] = { { "unlimited", INT_MAX, 0 }, { nullptr } }; defines an extra `unlimited' keyword and a user-visible 0 value, both of which get translated to INT_MAX for the setting to be used with. Similarly: const literal_def zuinteger_unlimited_literals[] = { { "unlimited", -1, -1 }, { nullptr } }; defines the same keyword and a corresponding user-visible -1 value that is used for the requested setting. If the last member were omitted (or set to `{}') here, then only the keyword would be allowed for the user to enter and while -1 would still be used internally trying to enter it as a part of a command would result in an "integer -1 out of range" error. Use said error message in all cases (citing the invalid value requested) replacing "only -1 is allowed to set as unlimited" previously used for `var_zuinteger_unlimited' settings only rather than propagating it to `var_pinteger' type. It could only be used for the specific case where a single extra `unlimited' keyword was defined standing for -1 and the use of numeric equivalents is discouraged anyway as it is for historical reasons only that they expose GDB internals, confusingly different across variable types. Similarly update the "must be >= -1" Guile error message. Redefine Guile and Python parameter types in terms of the new variable types and interpret extra keywords as Scheme keywords and Python strings used to communicate corresponding parameter values. Do not add a new PARAM_INTEGER Guile parameter type, however do handle the `var_integer' variable type now, permitting existing parameters defined by GDB proper, such as `listsize', to be accessed from Scheme code. With these changes in place it should be trivial for a Scheme or Python programmer to expand the syntax of the `make-parameter' command and the `gdb.Parameter' class initializer to have arbitrary extra literals along with their internal representation supplied. Update the testsuite accordingly. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-19 21:15:56 +00:00
/* Translation from Python parameters to GDB variable types. Keep in the
same order as PARAM_TYPES due to C++'s lack of designated initializers. */
static const struct
{
/* The type of the parameter. */
enum var_types type;
/* Extra literals, such as `unlimited', accepted in lieu of a number. */
const literal_def *extra_literals;
}
param_to_var[] =
{
{ var_boolean },
{ var_auto_boolean },
{ var_uinteger, uinteger_unlimited_literals },
{ var_integer, integer_unlimited_literals },
{ var_string },
{ var_string_noescape },
{ var_optional_filename },
{ var_filename },
{ var_integer },
{ var_uinteger },
{ var_pinteger, pinteger_unlimited_literals },
{ var_enum },
{ var_color }
GDB: Allow arbitrary keywords in integer set commands Rather than just `unlimited' allow the integer set commands (or command options) to define arbitrary keywords for the user to use, removing hardcoded arrangements for the `unlimited' keyword. Remove the confusingly named `var_zinteger', `var_zuinteger' and `var_zuinteger_unlimited' `set'/`show' command variable types redefining them in terms of `var_uinteger', `var_integer' and `var_pinteger', which have the range of [0;UINT_MAX], [INT_MIN;INT_MAX], and [0;INT_MAX] each. Following existing practice `var_pinteger' allows extra negative values to be used, however unlike `var_zuinteger_unlimited' any number of such values can be defined rather than just `-1'. The "p" in `var_pinteger' stands for "positive", for the lack of a more appropriate unambiguous letter, even though 0 obviously is not positive; "n" would be confusing as to whether it stands for "non-negative" or "negative". Add a new structure, `literal_def', the entries of which define extra keywords allowed for a command and numerical values they correspond to. Those values are not verified against the basic range supported by the underlying variable type, allowing extra values to be allowed outside that range, which may or may not be individually made visible to the user. An optional value translation is possible with the structure to follow the existing practice for some commands where user-entered 0 is internally translated to UINT_MAX or INT_MAX. Such translation can now be arbitrary. Literals defined by this structure are automatically used for completion as necessary. So for example: const literal_def integer_unlimited_literals[] = { { "unlimited", INT_MAX, 0 }, { nullptr } }; defines an extra `unlimited' keyword and a user-visible 0 value, both of which get translated to INT_MAX for the setting to be used with. Similarly: const literal_def zuinteger_unlimited_literals[] = { { "unlimited", -1, -1 }, { nullptr } }; defines the same keyword and a corresponding user-visible -1 value that is used for the requested setting. If the last member were omitted (or set to `{}') here, then only the keyword would be allowed for the user to enter and while -1 would still be used internally trying to enter it as a part of a command would result in an "integer -1 out of range" error. Use said error message in all cases (citing the invalid value requested) replacing "only -1 is allowed to set as unlimited" previously used for `var_zuinteger_unlimited' settings only rather than propagating it to `var_pinteger' type. It could only be used for the specific case where a single extra `unlimited' keyword was defined standing for -1 and the use of numeric equivalents is discouraged anyway as it is for historical reasons only that they expose GDB internals, confusingly different across variable types. Similarly update the "must be >= -1" Guile error message. Redefine Guile and Python parameter types in terms of the new variable types and interpret extra keywords as Scheme keywords and Python strings used to communicate corresponding parameter values. Do not add a new PARAM_INTEGER Guile parameter type, however do handle the `var_integer' variable type now, permitting existing parameters defined by GDB proper, such as `listsize', to be accessed from Scheme code. With these changes in place it should be trivial for a Scheme or Python programmer to expand the syntax of the `make-parameter' command and the `gdb.Parameter' class initializer to have arbitrary extra literals along with their internal representation supplied. Update the testsuite accordingly. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-19 21:15:56 +00:00
};
/* Parameter constants and their values. */
gdb: make some variables static I'm trying to enable clang's -Wmissing-variable-declarations warning. This patch fixes all the obvious spots where we can simply add "static" (at least, found when building on x86-64 Linux). gdb/ChangeLog: * aarch64-linux-tdep.c (aarch64_linux_record_tdep): Make static. * aarch64-tdep.c (tdesc_aarch64_list, aarch64_prologue_unwind, aarch64_stub_unwind, aarch64_normal_base, ): Make static. * arm-linux-tdep.c (arm_prologue_unwind): Make static. * arm-tdep.c (struct frame_unwind): Make static. * auto-load.c (auto_load_safe_path_vec): Make static. * csky-tdep.c (csky_stub_unwind): Make static. * gdbarch.c (gdbarch_data_registry): Make static. * gnu-v2-abi.c (gnu_v2_abi_ops): Make static. * i386-netbsd-tdep.c (i386nbsd_mc_reg_offset): Make static. * i386-tdep.c (i386_frame_setup_skip_insns, i386_tramp_chain_in_reg_insns, i386_tramp_chain_on_stack_insns): Make static. * infrun.c (observer_mode): Make static. * linux-nat.c (sigchld_action): Make static. * linux-thread-db.c (thread_db_list): Make static. * maint-test-options.c (maintenance_test_options_list): * mep-tdep.c (mep_csr_registers): Make static. * mi/mi-cmds.c (struct mi_cmd_stats): Remove struct type name. (stats): Make static. * nat/linux-osdata.c (struct osdata_type): Make static. * ppc-netbsd-tdep.c (ppcnbsd_reg_offsets): Make static. * progspace.c (last_program_space_num): Make static. * python/py-param.c (struct parm_constant): Remove struct type name. (parm_constants): Make static. * python/py-record-btrace.c (btpy_list_methods): Make static. * python/py-record.c (recpy_gap_type): Make static. * record.c (record_goto_cmdlist): Make static. * regcache.c (regcache_descr_handle): Make static. * registry.h (DEFINE_REGISTRY): Make definition static. * symmisc.c (std_in, std_out, std_err): Make static. * top.c (previous_saved_command_line): Make static. * tracepoint.c (trace_user, trace_notes, trace_stop_notes): Make static. * unittests/command-def-selftests.c (nr_duplicates, nr_invalid_prefixcmd, lists): Make static. * unittests/observable-selftests.c (test_notification): Make static. * unittests/optional/assignment/1.cc (counter): Make static. * unittests/optional/assignment/2.cc (counter): Make static. * unittests/optional/assignment/3.cc (counter): Make static. * unittests/optional/assignment/4.cc (counter): Make static. * unittests/optional/assignment/5.cc (counter): Make static. * unittests/optional/assignment/6.cc (counter): Make static. gdbserver/ChangeLog: * ax.cc (bytecode_address_table): Make static. * debug.cc (debug_file): Make static. * linux-low.cc (stopping_threads): Make static. (step_over_bkpt): Make static. * linux-x86-low.cc (amd64_emit_ops, i386_emit_ops): Make static. * tracepoint.cc (stop_tracing_bkpt, flush_trace_buffer_bkpt, alloced_trace_state_variables, trace_buffer_ctrl, tracing_start_time, tracing_stop_time, tracing_user_name, tracing_notes, tracing_stop_note): Make static. Change-Id: Ic1d8034723b7802502bda23770893be2338ab020
2021-01-20 20:55:05 -05:00
static struct {
-Wwrite-strings: The Rest This is the remainder boring constification that all looks more of less borderline obvious IMO. gdb/ChangeLog: 2017-04-05 Pedro Alves <palves@redhat.com> * ada-exp.y (yyerror): Constify. * ada-lang.c (bound_name, get_selections) (ada_variant_discrim_type) (ada_variant_discrim_name, ada_value_struct_elt) (ada_lookup_struct_elt_type, is_unchecked_variant) (ada_which_variant_applies, standard_exc, ada_get_next_arg) (catch_ada_exception_command_split) (catch_ada_assert_command_split, catch_assert_command) (ada_op_name): Constify. * ada-lang.h (ada_yyerror, get_selections) (ada_variant_discrim_name, ada_value_struct_elt): Constify. * arc-tdep.c (arc_print_frame_cache): Constify. * arm-tdep.c (arm_skip_stub): Constify. * ax-gdb.c (gen_binop, gen_struct_ref_recursive, gen_struct_ref) (gen_aggregate_elt_ref): Constify. * bcache.c (print_bcache_statistics): Constify. * bcache.h (print_bcache_statistics): Constify. * break-catch-throw.c (catch_exception_command_1): * breakpoint.c (struct ep_type_description::description): Constify. (add_solib_catchpoint): Constify. (catch_fork_command_1): Add cast. (add_catch_command): Constify. * breakpoint.h (add_catch_command, add_solib_catchpoint): Constify. * bsd-uthread.c (bsd_uthread_state): Constify. * buildsym.c (patch_subfile_names): Constify. * buildsym.h (next_symbol_text_func, patch_subfile_names): Constify. * c-exp.y (yyerror): Constify. (token::oper): Constify. * c-lang.h (c_yyerror, cp_print_class_member): Constify. * c-varobj.c (cplus_describe_child): Constify. * charset.c (find_charset_names): Add cast. (find_charset_names): Constify array and add const_cast. * cli/cli-cmds.c (complete_command, cd_command): Constify. (edit_command): Constify. * cli/cli-decode.c (lookup_cmd): Constify. * cli/cli-dump.c (dump_memory_command, dump_value_command): Constify. (struct dump_context): Constify. (add_dump_command, restore_command): Constify. * cli/cli-script.c (get_command_line): Constify. * cli/cli-script.h (get_command_line): Constify. * cli/cli-utils.c (check_for_argument): Constify. * cli/cli-utils.h (check_for_argument): Constify. * coff-pe-read.c (struct read_pe_section_data): Constify. * command.h (lookup_cmd): Constify. * common/print-utils.c (decimal2str): Constify. * completer.c (gdb_print_filename): Constify. * corefile.c (set_gnutarget): Constify. * cp-name-parser.y (yyerror): Constify. * cp-valprint.c (cp_print_class_member): Constify. * cris-tdep.c (cris_register_name, crisv32_register_name): Constify. * d-exp.y (yyerror): Constify. (struct token::oper): Constify. * d-lang.h (d_yyerror): Constify. * dbxread.c (struct header_file_location::name): Constify. (add_old_header_file, add_new_header_file, last_function_name) (dbx_next_symbol_text, add_bincl_to_list) (find_corresponding_bincl_psymtab, set_namestring) (find_stab_function_addr, read_dbx_symtab, start_psymtab) (dbx_end_psymtab, read_ofile_symtab, process_one_symbol): * defs.h (command_line_input, print_address_symbolic) (deprecated_readline_begin_hook): Constify. * dwarf2read.c (anonymous_struct_prefix, dwarf_bool_name): Constify. * event-top.c (handle_line_of_input): Constify and add cast. * exceptions.c (catch_errors): Constify. * exceptions.h (catch_errors): Constify. * expprint.c (print_subexp_standard, op_string, op_name) (op_name_standard, dump_raw_expression, dump_raw_expression): * expression.h (op_name, op_string, dump_raw_expression): Constify. * f-exp.y (yyerror): Constify. (struct token::oper): Constify. (struct f77_boolean_val::name): Constify. * f-lang.c (f_word_break_characters): Constify. * f-lang.h (f_yyerror): Constify. * fork-child.c (fork_inferior): Add cast. * frv-tdep.c (struct gdbarch_tdep::register_names): Constify. (new_variant): Constify. * gdbarch.sh (pstring_ptr, pstring_list): Constify. * gdbarch.c: Regenerate. * gdbcore.h (set_gnutarget): Constify. * go-exp.y (yyerror): Constify. (token::oper): Constify. * go-lang.h (go_yyerror): Constify. * go32-nat.c (go32_sysinfo): Constify. * guile/scm-breakpoint.c (gdbscm_breakpoint_expression): Constify. * guile/scm-cmd.c (cmdscm_function): Constify. * guile/scm-param.c (pascm_param_value): Constify. * h8300-tdep.c (h8300_register_name, h8300s_register_name) (h8300sx_register_name): Constify. * hppa-tdep.c (hppa32_register_name, hppa64_register_name): Constify. * ia64-tdep.c (ia64_register_names): Constify. * infcmd.c (construct_inferior_arguments): Constify. (path_command, attach_post_wait): Constify. * language.c (show_range_command, show_case_command) (unk_lang_error): Constify. * language.h (language_defn::la_error) (language_defn::la_name_of_this): Constify. * linespec.c (decode_line_2): Constify. * linux-thread-db.c (thread_db_err_str): Constify. * lm32-tdep.c (lm32_register_name): Constify. * m2-exp.y (yyerror): Constify. * m2-lang.h (m2_yyerror): Constify. * m32r-tdep.c (m32r_register_names): Constify and make static. * m68hc11-tdep.c (m68hc11_register_names): Constify. * m88k-tdep.c (m88k_register_name): Constify. * macroexp.c (appendmem): Constify. * mdebugread.c (fdr_name, add_data_symbol, parse_type) (upgrade_type, parse_external, parse_partial_symbols) (mdebug_next_symbol_text, cross_ref, mylookup_symbol, new_psymtab) (new_symbol): Constify. * memattr.c (mem_info_command): Constify. * mep-tdep.c (register_name_from_keyword): Constify. * mi/mi-cmd-env.c (mi_cmd_env_path, _initialize_mi_cmd_env): Constify. * mi/mi-cmd-stack.c (list_args_or_locals): Constify. * mi/mi-cmd-var.c (mi_cmd_var_show_attributes): Constify. * mi/mi-main.c (captured_mi_execute_command): Constify and add cast. (mi_execute_async_cli_command): Constify. * mips-tdep.c (mips_register_name): Constify. * mn10300-tdep.c (register_name, mn10300_generic_register_name) (am33_register_name, am33_2_register_name) * moxie-tdep.c (moxie_register_names): Constify. * nat/linux-osdata.c (osdata_type): Constify fields. * nto-tdep.c (nto_parse_redirection): Constify. * objc-lang.c (lookup_struct_typedef, lookup_objc_class) (lookup_child_selector): Constify. (objc_methcall::name): Constify. * objc-lang.h (lookup_objc_class, lookup_child_selector) (lookup_struct_typedef): Constify. * objfiles.c (pc_in_section): Constify. * objfiles.h (pc_in_section): Constify. * p-exp.y (struct token::oper): Constify. (yyerror): Constify. * p-lang.h (pascal_yyerror): Constify. * parser-defs.h (op_name_standard): Constify. (op_print::string): Constify. (exp_descriptor::op_name): Constify. * printcmd.c (print_address_symbolic): Constify. * psymtab.c (print_partial_symbols): Constify. * python/py-breakpoint.c (stop_func): Constify. (bppy_get_expression): Constify. * python/py-cmd.c (cmdpy_completer::name): Constify. (cmdpy_function): Constify. * python/py-event.c (evpy_add_attribute) (gdbpy_initialize_event_generic): Constify. * python/py-event.h (evpy_add_attribute) (gdbpy_initialize_event_generic): Constify. * python/py-evts.c (add_new_registry): Constify. * python/py-finishbreakpoint.c (outofscope_func): Constify. * python/py-framefilter.c (get_py_iter_from_func): Constify. * python/py-inferior.c (get_buffer): Add cast. * python/py-param.c (parm_constant::name): Constify. * python/py-unwind.c (fprint_frame_id): Constify. * python/python.c (gdbpy_parameter_value): Constify. * remote-fileio.c (remote_fio_func_map): Make 'name' const. * remote.c (memory_packet_config::name): Constify. (show_packet_config_cmd, remote_write_bytes) (remote_buffer_add_string): * reverse.c (exec_reverse_once): Constify. * rs6000-tdep.c (variant::name, variant::description): Constify. * rust-exp.y (rustyyerror): Constify. * rust-lang.c (rust_op_name): Constify. * rust-lang.h (rustyyerror): Constify. * serial.h (serial_ops::name): Constify. * sh-tdep.c (sh_sh_register_name, sh_sh3_register_name) (sh_sh3e_register_name, sh_sh2e_register_name) (sh_sh2a_register_name, sh_sh2a_nofpu_register_name) (sh_sh_dsp_register_name, sh_sh3_dsp_register_name) (sh_sh4_register_name, sh_sh4_nofpu_register_name) (sh_sh4al_dsp_register_name): Constify. * sh64-tdep.c (sh64_register_name): Constify. * solib-darwin.c (lookup_symbol_from_bfd): Constify. * spu-tdep.c (spu_register_name, info_spu_dma_cmdlist): Constify. * stabsread.c (patch_block_stabs, read_type_number) (ref_map::stabs, ref_add, process_reference) (symbol_reference_defined, define_symbol, define_symbol) (error_type, read_type, read_member_functions, read_cpp_abbrev) (read_one_struct_field, read_struct_fields, read_baseclasses) (read_tilde_fields, read_struct_type, read_array_type) (read_enum_type, read_sun_builtin_type, read_sun_floating_type) (read_huge_number, read_range_type, read_args, common_block_start) (find_name_end): Constify. * stabsread.h (common_block_start, define_symbol) (process_one_symbol, symbol_reference_defined, ref_add): * symfile.c (get_section_index, add_symbol_file_command): * symfile.h (get_section_index): Constify. * target-descriptions.c (tdesc_type::name): Constify. (tdesc_free_type): Add cast. * target.c (find_default_run_target): (add_deprecated_target_alias, find_default_run_target) (target_announce_detach): Constify. (do_option): Constify. * target.h (add_deprecated_target_alias): Constify. * thread.c (print_thread_info_1): Constify. * top.c (deprecated_readline_begin_hook, command_line_input): Constify. (init_main): Add casts. * top.h (handle_line_of_input): Constify. * tracefile-tfile.c (tfile_write_uploaded_tsv): Constify. * tracepoint.c (tvariables_info_1, trace_status_mi): Constify. (tfind_command): Rename to ... (tfind_command_1): ... this and constify. (tfind_command): New function. (tfind_end_command, tfind_start_command): Adjust. (encode_source_string): Constify. * tracepoint.h (encode_source_string): Constify. * tui/tui-data.c (tui_partial_win_by_name): Constify. * tui/tui-data.h (tui_partial_win_by_name): Constify. * tui/tui-source.c (tui_set_source_content_nil): Constify. * tui/tui-source.h (tui_set_source_content_nil): Constify. * tui/tui-win.c (parse_scrolling_args): Constify. * tui/tui-windata.c (tui_erase_data_content): Constify. * tui/tui-windata.h (tui_erase_data_content): Constify. * tui/tui-winsource.c (tui_erase_source_content): Constify. * tui/tui.c (tui_enable): Add cast. * utils.c (defaulted_query): Constify. (init_page_info): Add cast. (puts_debug, subset_compare): Constify. * utils.h (subset_compare): Constify. * varobj.c (varobj_format_string): Constify. * varobj.h (varobj_format_string): Constify. * vax-tdep.c (vax_register_name): Constify. * windows-nat.c (windows_detach): Constify. * xcoffread.c (process_linenos, xcoff_next_symbol_text): Constify. * xml-support.c (gdb_xml_end_element): Constify. * xml-tdesc.c (tdesc_start_reg): Constify. * xstormy16-tdep.c (xstormy16_register_name): Constify. * xtensa-tdep.c (xtensa_find_register_by_name): Constify. * xtensa-tdep.h (xtensa_register_t::name): Constify. gdb/gdbserver/ChangeLog: 2017-04-05 Pedro Alves <palves@redhat.com> * gdbreplay.c (sync_error): Constify. * linux-x86-low.c (push_opcode): Constify.
2017-04-05 19:21:37 +01:00
const char *name;
int value;
gdb: make some variables static I'm trying to enable clang's -Wmissing-variable-declarations warning. This patch fixes all the obvious spots where we can simply add "static" (at least, found when building on x86-64 Linux). gdb/ChangeLog: * aarch64-linux-tdep.c (aarch64_linux_record_tdep): Make static. * aarch64-tdep.c (tdesc_aarch64_list, aarch64_prologue_unwind, aarch64_stub_unwind, aarch64_normal_base, ): Make static. * arm-linux-tdep.c (arm_prologue_unwind): Make static. * arm-tdep.c (struct frame_unwind): Make static. * auto-load.c (auto_load_safe_path_vec): Make static. * csky-tdep.c (csky_stub_unwind): Make static. * gdbarch.c (gdbarch_data_registry): Make static. * gnu-v2-abi.c (gnu_v2_abi_ops): Make static. * i386-netbsd-tdep.c (i386nbsd_mc_reg_offset): Make static. * i386-tdep.c (i386_frame_setup_skip_insns, i386_tramp_chain_in_reg_insns, i386_tramp_chain_on_stack_insns): Make static. * infrun.c (observer_mode): Make static. * linux-nat.c (sigchld_action): Make static. * linux-thread-db.c (thread_db_list): Make static. * maint-test-options.c (maintenance_test_options_list): * mep-tdep.c (mep_csr_registers): Make static. * mi/mi-cmds.c (struct mi_cmd_stats): Remove struct type name. (stats): Make static. * nat/linux-osdata.c (struct osdata_type): Make static. * ppc-netbsd-tdep.c (ppcnbsd_reg_offsets): Make static. * progspace.c (last_program_space_num): Make static. * python/py-param.c (struct parm_constant): Remove struct type name. (parm_constants): Make static. * python/py-record-btrace.c (btpy_list_methods): Make static. * python/py-record.c (recpy_gap_type): Make static. * record.c (record_goto_cmdlist): Make static. * regcache.c (regcache_descr_handle): Make static. * registry.h (DEFINE_REGISTRY): Make definition static. * symmisc.c (std_in, std_out, std_err): Make static. * top.c (previous_saved_command_line): Make static. * tracepoint.c (trace_user, trace_notes, trace_stop_notes): Make static. * unittests/command-def-selftests.c (nr_duplicates, nr_invalid_prefixcmd, lists): Make static. * unittests/observable-selftests.c (test_notification): Make static. * unittests/optional/assignment/1.cc (counter): Make static. * unittests/optional/assignment/2.cc (counter): Make static. * unittests/optional/assignment/3.cc (counter): Make static. * unittests/optional/assignment/4.cc (counter): Make static. * unittests/optional/assignment/5.cc (counter): Make static. * unittests/optional/assignment/6.cc (counter): Make static. gdbserver/ChangeLog: * ax.cc (bytecode_address_table): Make static. * debug.cc (debug_file): Make static. * linux-low.cc (stopping_threads): Make static. (step_over_bkpt): Make static. * linux-x86-low.cc (amd64_emit_ops, i386_emit_ops): Make static. * tracepoint.cc (stop_tracing_bkpt, flush_trace_buffer_bkpt, alloced_trace_state_variables, trace_buffer_ctrl, tracing_start_time, tracing_stop_time, tracing_user_name, tracing_notes, tracing_stop_note): Make static. Change-Id: Ic1d8034723b7802502bda23770893be2338ab020
2021-01-20 20:55:05 -05:00
} parm_constants[] =
{
{ "PARAM_BOOLEAN", param_boolean },
GDB: Allow arbitrary keywords in integer set commands Rather than just `unlimited' allow the integer set commands (or command options) to define arbitrary keywords for the user to use, removing hardcoded arrangements for the `unlimited' keyword. Remove the confusingly named `var_zinteger', `var_zuinteger' and `var_zuinteger_unlimited' `set'/`show' command variable types redefining them in terms of `var_uinteger', `var_integer' and `var_pinteger', which have the range of [0;UINT_MAX], [INT_MIN;INT_MAX], and [0;INT_MAX] each. Following existing practice `var_pinteger' allows extra negative values to be used, however unlike `var_zuinteger_unlimited' any number of such values can be defined rather than just `-1'. The "p" in `var_pinteger' stands for "positive", for the lack of a more appropriate unambiguous letter, even though 0 obviously is not positive; "n" would be confusing as to whether it stands for "non-negative" or "negative". Add a new structure, `literal_def', the entries of which define extra keywords allowed for a command and numerical values they correspond to. Those values are not verified against the basic range supported by the underlying variable type, allowing extra values to be allowed outside that range, which may or may not be individually made visible to the user. An optional value translation is possible with the structure to follow the existing practice for some commands where user-entered 0 is internally translated to UINT_MAX or INT_MAX. Such translation can now be arbitrary. Literals defined by this structure are automatically used for completion as necessary. So for example: const literal_def integer_unlimited_literals[] = { { "unlimited", INT_MAX, 0 }, { nullptr } }; defines an extra `unlimited' keyword and a user-visible 0 value, both of which get translated to INT_MAX for the setting to be used with. Similarly: const literal_def zuinteger_unlimited_literals[] = { { "unlimited", -1, -1 }, { nullptr } }; defines the same keyword and a corresponding user-visible -1 value that is used for the requested setting. If the last member were omitted (or set to `{}') here, then only the keyword would be allowed for the user to enter and while -1 would still be used internally trying to enter it as a part of a command would result in an "integer -1 out of range" error. Use said error message in all cases (citing the invalid value requested) replacing "only -1 is allowed to set as unlimited" previously used for `var_zuinteger_unlimited' settings only rather than propagating it to `var_pinteger' type. It could only be used for the specific case where a single extra `unlimited' keyword was defined standing for -1 and the use of numeric equivalents is discouraged anyway as it is for historical reasons only that they expose GDB internals, confusingly different across variable types. Similarly update the "must be >= -1" Guile error message. Redefine Guile and Python parameter types in terms of the new variable types and interpret extra keywords as Scheme keywords and Python strings used to communicate corresponding parameter values. Do not add a new PARAM_INTEGER Guile parameter type, however do handle the `var_integer' variable type now, permitting existing parameters defined by GDB proper, such as `listsize', to be accessed from Scheme code. With these changes in place it should be trivial for a Scheme or Python programmer to expand the syntax of the `make-parameter' command and the `gdb.Parameter' class initializer to have arbitrary extra literals along with their internal representation supplied. Update the testsuite accordingly. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-19 21:15:56 +00:00
{ "PARAM_AUTO_BOOLEAN", param_auto_boolean },
{ "PARAM_UINTEGER", param_uinteger },
{ "PARAM_INTEGER", param_integer },
{ "PARAM_STRING", param_string },
{ "PARAM_STRING_NOESCAPE", param_string_noescape },
{ "PARAM_OPTIONAL_FILENAME", param_optional_filename },
{ "PARAM_FILENAME", param_filename },
{ "PARAM_ZINTEGER", param_zinteger },
{ "PARAM_ZUINTEGER", param_zuinteger },
{ "PARAM_ZUINTEGER_UNLIMITED", param_zuinteger_unlimited },
{ "PARAM_ENUM", param_enum },
{ "PARAM_COLOR", param_color },
{ NULL, 0 }
};
/* A union that can hold anything described by enum var_types. */
union parmpy_variable
{
Change boolean options to bool instead of int This is for add_setshow_boolean_cmd as well as the gdb::option interface. gdb/ChangeLog: 2019-09-17 Christian Biesinger <cbiesinger@google.com> * ada-lang.c (ada_ignore_descriptive_types_p): Change to bool. (print_signatures): Likewise. (trust_pad_over_xvs): Likewise. * arch/aarch64-insn.c (aarch64_debug): Likewise. * arch/aarch64-insn.h (aarch64_debug): Likewise. * arm-linux-nat.c (arm_apcs_32): Likewise. * arm-linux-tdep.c (arm_apcs_32): Likewise. * arm-nbsd-nat.c (arm_apcs_32): Likewise. * arm-tdep.c (arm_debug): Likewise. (arm_apcs_32): Likewise. * auto-load.c (debug_auto_load): Likewise. (auto_load_gdb_scripts): Likewise. (global_auto_load): Likewise. (auto_load_local_gdbinit): Likewise. (auto_load_local_gdbinit_loaded): Likewise. * auto-load.h (global_auto_load): Likewise. (auto_load_local_gdbinit): Likewise. (auto_load_local_gdbinit_loaded): Likewise. * breakpoint.c (disconnected_dprintf): Likewise. (breakpoint_proceeded): Likewise. (automatic_hardware_breakpoints): Likewise. (always_inserted_mode): Likewise. (target_exact_watchpoints): Likewise. (_initialize_breakpoint): Update. * breakpoint.h (target_exact_watchpoints): Change to bool. * btrace.c (maint_btrace_pt_skip_pad): Likewise. * cli/cli-cmds.c (trace_commands): Likewise. * cli/cli-cmds.h (trace_commands): Likewise. * cli/cli-decode.c (add_setshow_boolean_cmd): Change int* argument to bool*. * cli/cli-logging.c (logging_overwrite): Change to bool. (logging_redirect): Likewise. (debug_redirect): Likewise. * cli/cli-option.h (option_def) <boolean>: Change return type to bool*. (struct boolean_option_def) <get_var_address_cb_>: Change return type to bool. <boolean_option_def>: Update. (struct flag_option_def): Change default type of Context to bool from int. <flag_option_def>: Change return type of var_address_cb_ to bool*. * cli/cli-setshow.c (do_set_command): Cast to bool* instead of int*. (get_setshow_command_value_string): Likewise. * cli/cli-style.c (cli_styling): Change to bool. (source_styling): Likewise. * cli/cli-style.h (source_styling): Likewise. (cli_styling): Likewise. * cli/cli-utils.h (struct qcs_flags) <quiet, cont, silent>: Change to bool. * command.h (var_types): Update comment. (add_setshow_boolean_cmd): Change int* var argument to bool*. * compile/compile-cplus-types.c (debug_compile_cplus_types): Change to bool. (debug_compile_cplus_scopes): Likewise. * compile/compile-internal.h (compile_debug): Likewise. * compile/compile.c (compile_debug): Likewise. (struct compile_options) <raw>: Likewise. * cp-support.c (catch_demangler_crashes): Likewise. * cris-tdep.c (usr_cmd_cris_version_valid): Likewise. (usr_cmd_cris_dwarf2_cfi): Likewise. * csky-tdep.c (csky_debug): Likewise. * darwin-nat.c (enable_mach_exceptions): Likewise. * dcache.c (dcache_enabled_p): Likewise. * defs.h (info_verbose): Likewise. * demangle.c (demangle): Likewise. (asm_demangle): Likewise. * dwarf-index-cache.c (debug_index_cache): Likewise. * dwarf2-frame.c (dwarf2_frame_unwinders_enabled_p): Likewise. * dwarf2-frame.h (dwarf2_frame_unwinders_enabled_p): Likewise. * dwarf2read.c (check_physname): Likewise. (use_deprecated_index_sections): Likewise. (dwarf_always_disassemble): Likewise. * eval.c (overload_resolution): Likewise. * event-top.c (set_editing_cmd_var): Likewise. (exec_done_display_p): Likewise. * event-top.h (set_editing_cmd_var): Likewise. (exec_done_display_p): Likewise. * exec.c (write_files): Likewise. * fbsd-nat.c (debug_fbsd_lwp): Likewise (debug_fbsd_nat): Likewise. * frame.h (struct frame_print_options) <print_raw_frame_arguments>: Likewise. (struct set_backtrace_options) <backtrace_past_main>: Likewise. <backtrace_past_entry> Likewise. * gdb-demangle.h (demangle): Likewise. (asm_demangle): Likewise. * gdb_bfd.c (bfd_sharing): Likewise. * gdbcore.h (write_files): Likewise. * gdbsupport/common-debug.c (show_debug_regs): Likewise. * gdbsupport/common-debug.h (show_debug_regs): Likewise. * gdbthread.h (print_thread_events): Likewise. * gdbtypes.c (opaque_type_resolution): Likewise. (strict_type_checking): Likewise. * gnu-nat.c (gnu_debug_flag): Likewise. * guile/scm-auto-load.c (auto_load_guile_scripts): Likewise. * guile/scm-param.c (pascm_variable): Add boolval. (add_setshow_generic): Update. (pascm_param_value): Update. (pascm_set_param_value_x): Update. * hppa-tdep.c (hppa_debug): Change to bool.. * infcall.c (may_call_functions_p): Likewise. (coerce_float_to_double_p): Likewise. (unwind_on_signal_p): Likewise. (unwind_on_terminating_exception_p): Likewise. * infcmd.c (startup_with_shell): Likewise. * inferior.c (print_inferior_events): Likewise. * inferior.h (startup_with_shell): Likewise. (print_inferior_events): Likewise. * infrun.c (step_stop_if_no_debug): Likewise. (detach_fork): Likewise. (debug_displaced): Likewise. (disable_randomization): Likewise. (non_stop): Likewise. (non_stop_1): Likewise. (observer_mode): Likewise. (observer_mode_1): Likewise. (set_observer_mode): Update. (sched_multi): Change to bool. * infrun.h (debug_displaced): Likewise. (sched_multi): Likewise. (step_stop_if_no_debug): Likewise. (non_stop): Likewise. (disable_randomization): Likewise. * linux-tdep.c (use_coredump_filter): Likewise. (dump_excluded_mappings): Likewise. * linux-thread-db.c (auto_load_thread_db): Likewise. (check_thread_db_on_load): Likewise. * main.c (captured_main_1): Update. * maint-test-options.c (struct test_options_opts) <flag_opt, xx1_opt, xx2_opt, boolean_opt>: Change to bool. * maint-test-settings.c (maintenance_test_settings_boolean): Likewise. * maint.c (maintenance_profile_p): Likewise. (per_command_time): Likewise. (per_command_space): Likewise. (per_command_symtab): Likewise. * memattr.c (inaccessible_by_default): Likewise. * mi/mi-main.c (mi_async): Likewise. (mi_async_1): Likewise. * mips-tdep.c (mips64_transfers_32bit_regs_p): Likewise. * nat/fork-inferior.h (startup_with_shell): Likewise. * nat/linux-namespaces.c (debug_linux_namespaces): Likewise. * nat/linux-namespaces.h (debug_linux_namespaces): Likewise. * nios2-tdep.c (nios2_debug): Likewise. * or1k-tdep.c (or1k_debug): Likewise. * parse.c (parser_debug): Likewise. * parser-defs.h (parser_debug): Likewise. * printcmd.c (print_symbol_filename): Likewise. * proc-api.c (procfs_trace): Likewise. * python/py-auto-load.c (auto_load_python_scripts): Likewise. * python/py-param.c (union parmpy_variable): Add "bool boolval" field. (set_parameter_value): Update. (add_setshow_generic): Update. * python/py-value.c (copy_py_bool_obj): Change argument from int* to bool*. * python/python.c (gdbpy_parameter_value): Cast to bool* instead of int*. * ravenscar-thread.c (ravenscar_task_support): Change to bool. * record-btrace.c (record_btrace_target::store_registers): Update. * record-full.c (record_full_memory_query): Change to bool. (record_full_stop_at_limit): Likewise. * record-full.h (record_full_memory_query): Likewise. * remote-notif.c (notif_debug): Likewise. * remote-notif.h (notif_debug): Likewise. * remote.c (use_range_stepping): Likewise. (interrupt_on_connect): Likewise. (remote_break): Likewise. * ser-tcp.c (tcp_auto_retry): Likewise. * ser-unix.c (serial_hwflow): Likewise. * skip.c (debug_skip): Likewise. * solib-aix.c (solib_aix_debug): Likewise. * spu-tdep.c (spu_stop_on_load_p): Likewise. (spu_auto_flush_cache_p): Likewise. * stack.c (struct backtrace_cmd_options) <full, no_filters, hide>: Likewise. (struct info_print_options) <quiet>: Likewise. * symfile-debug.c (debug_symfile): Likewise. * symfile.c (auto_solib_add): Likewise. (separate_debug_file_debug): Likewise. * symfile.h (auto_solib_add): Likewise. (separate_debug_file_debug): Likewise. * symtab.c (basenames_may_differ): Likewise. (struct filename_partial_match_opts) <dirname, basename>: Likewise. (struct info_print_options) <quiet, exclude_minsyms>: Likewise. (struct info_types_options) <quiet>: Likewise. * symtab.h (demangle): Likewise. (basenames_may_differ): Likewise. * target-dcache.c (stack_cache_enabled_1): Likewise. (code_cache_enabled_1): Likewise. * target.c (trust_readonly): Likewise. (may_write_registers): Likewise. (may_write_memory): Likewise. (may_insert_breakpoints): Likewise. (may_insert_tracepoints): Likewise. (may_insert_fast_tracepoints): Likewise. (may_stop): Likewise. (auto_connect_native_target): Likewise. (target_stop_and_wait): Update. (target_async_permitted): Change to bool. (target_async_permitted_1): Likewise. (may_write_registers_1): Likewise. (may_write_memory_1): Likewise. (may_insert_breakpoints_1): Likewise. (may_insert_tracepoints_1): Likewise. (may_insert_fast_tracepoints_1): Likewise. (may_stop_1): Likewise. * target.h (target_async_permitted): Likewise. (may_write_registers): Likewise. (may_write_memory): Likewise. (may_insert_breakpoints): Likewise. (may_insert_tracepoints): Likewise. (may_insert_fast_tracepoints): Likewise. (may_stop): Likewise. * thread.c (struct info_threads_opts) <show_global_ids>: Likewise. (make_thread_apply_all_options_def_group): Change argument from int* to bool*. (thread_apply_all_command): Update. (print_thread_events): Change to bool. * top.c (confirm): Likewise. (command_editing_p): Likewise. (history_expansion_p): Likewise. (write_history_p): Likewise. (info_verbose): Likewise. * top.h (confirm): Likewise. (history_expansion_p): Likewise. * tracepoint.c (disconnected_tracing): Likewise. (circular_trace_buffer): Likewise. * typeprint.c (print_methods): Likewise. (print_typedefs): Likewise. * utils.c (debug_timestamp): Likewise. (sevenbit_strings): Likewise. (pagination_enabled): Likewise. * utils.h (sevenbit_strings): Likewise. (pagination_enabled): Likewise. * valops.c (overload_resolution): Likewise. * valprint.h (struct value_print_options) <prettyformat_arrays, prettyformat_structs, vtblprint, unionprint, addressprint, objectprint, stop_print_at_null, print_array_indexes, deref_ref, static_field_print, pascal_static_field_print, raw, summary, symbol_print, finish_print>: Likewise. * windows-nat.c (new_console): Likewise. (cygwin_exceptions): Likewise. (new_group): Likewise. (debug_exec): Likewise. (debug_events): Likewise. (debug_memory): Likewise. (debug_exceptions): Likewise. (useshell): Likewise. * windows-tdep.c (maint_display_all_tib): Likewise. * xml-support.c (debug_xml): Likewise.
2019-09-14 15:36:58 -04:00
/* Hold a boolean value. */
bool boolval;
/* Hold an integer value. */
int intval;
/* Hold an auto_boolean. */
enum auto_boolean autoboolval;
/* Hold an unsigned integer value, for uinteger. */
unsigned int uintval;
gdb: make string-like set show commands use std::string variable String-like settings (var_string, var_filename, var_optional_filename, var_string_noescape) currently take a pointer to a `char *` storage variable (typically global) that holds the setting's value. I'd like to "mordernize" this by changing them to use an std::string for storage. An obvious reason is that string operations on std::string are often easier to write than with C strings. And they avoid having to do any manual memory management. Another interesting reason is that, with `char *`, nullptr and an empty string often both have the same meaning of "no value". String settings are initially nullptr (unless initialized otherwise). But when doing "set foo" (where `foo` is a string setting), the setting now points to an empty string. For example, solib_search_path is nullptr at startup, but points to an empty string after doing "set solib-search-path". This leads to some code that needs to check for both to check for "no value". Or some code that converts back and forth between NULL and "" when getting or setting the value. I find this very error-prone, because it is very easy to forget one or the other. With std::string, we at least know that the variable is not "NULL". There is only one way of representing an empty string setting, that is with an empty string. I was wondering whether the distinction between NULL and "" would be important for some setting, but it doesn't seem so. If that ever happens, it would be more C++-y and self-descriptive to use optional<string> anyway. Actually, there's one spot where this distinction mattered, it's in init_history, for the test gdb.base/gdbinit-history.exp. init_history sets the history filename to the default ".gdb_history" if it sees that the setting was never set - if history_filename is nullptr. If history_filename is an empty string, it means the setting was explicitly cleared, so it leaves it as-is. With the change to std::string, this distinction doesn't exist anymore. This can be fixed by moving the code that chooses a good default value for history_filename to _initialize_top. This is ran before -ex commands are processed, so an -ex command can then clear that value if needed (what gdb.base/gdbinit-history.exp tests). Another small improvement, in my opinion is that we can now easily give string parameters initial values, by simply initializing the global variables, instead of xstrdup-ing it in the _initialize function. In Python and Guile, when registering a string-like parameter, we allocate (with new) an std::string that is owned by the param_smob (in Guile) and the parmpy_object (in Python) objects. This patch started by changing all relevant add_setshow_* commands to take an `std::string *` instead of a `char **` and fixing everything that failed to build. That includes of course all string setting variable and their uses. string_option_def now uses an std::string also, because there's a connection between options and settings (see add_setshow_cmds_for_options). The add_path function in source.c is really complex and twisted, I'd rather not try to change it to work on an std::string right now. Instead, I added an overload that copies the std:string to a `char *` and back. This means more copying, but this is not used in a hot path at all, so I think it is acceptable. Change-Id: I92c50a1bdd8307141cdbacb388248e4e4fc08c93 Co-authored-by: Lancelot SIX <lsix@lancelotsix.com>
2021-09-10 17:10:13 -04:00
/* Hold a string, for the various string types. The std::string is
new-ed. */
std::string *stringval;
/* Hold a string, for enums. */
const char *cstringval;
/* Hold a color. */
ui_file_style::color color;
};
/* A GDB parameter. */
struct parmpy_object : public PyObject
{
/* The type of the parameter. */
enum var_types type;
GDB: Allow arbitrary keywords in integer set commands Rather than just `unlimited' allow the integer set commands (or command options) to define arbitrary keywords for the user to use, removing hardcoded arrangements for the `unlimited' keyword. Remove the confusingly named `var_zinteger', `var_zuinteger' and `var_zuinteger_unlimited' `set'/`show' command variable types redefining them in terms of `var_uinteger', `var_integer' and `var_pinteger', which have the range of [0;UINT_MAX], [INT_MIN;INT_MAX], and [0;INT_MAX] each. Following existing practice `var_pinteger' allows extra negative values to be used, however unlike `var_zuinteger_unlimited' any number of such values can be defined rather than just `-1'. The "p" in `var_pinteger' stands for "positive", for the lack of a more appropriate unambiguous letter, even though 0 obviously is not positive; "n" would be confusing as to whether it stands for "non-negative" or "negative". Add a new structure, `literal_def', the entries of which define extra keywords allowed for a command and numerical values they correspond to. Those values are not verified against the basic range supported by the underlying variable type, allowing extra values to be allowed outside that range, which may or may not be individually made visible to the user. An optional value translation is possible with the structure to follow the existing practice for some commands where user-entered 0 is internally translated to UINT_MAX or INT_MAX. Such translation can now be arbitrary. Literals defined by this structure are automatically used for completion as necessary. So for example: const literal_def integer_unlimited_literals[] = { { "unlimited", INT_MAX, 0 }, { nullptr } }; defines an extra `unlimited' keyword and a user-visible 0 value, both of which get translated to INT_MAX for the setting to be used with. Similarly: const literal_def zuinteger_unlimited_literals[] = { { "unlimited", -1, -1 }, { nullptr } }; defines the same keyword and a corresponding user-visible -1 value that is used for the requested setting. If the last member were omitted (or set to `{}') here, then only the keyword would be allowed for the user to enter and while -1 would still be used internally trying to enter it as a part of a command would result in an "integer -1 out of range" error. Use said error message in all cases (citing the invalid value requested) replacing "only -1 is allowed to set as unlimited" previously used for `var_zuinteger_unlimited' settings only rather than propagating it to `var_pinteger' type. It could only be used for the specific case where a single extra `unlimited' keyword was defined standing for -1 and the use of numeric equivalents is discouraged anyway as it is for historical reasons only that they expose GDB internals, confusingly different across variable types. Similarly update the "must be >= -1" Guile error message. Redefine Guile and Python parameter types in terms of the new variable types and interpret extra keywords as Scheme keywords and Python strings used to communicate corresponding parameter values. Do not add a new PARAM_INTEGER Guile parameter type, however do handle the `var_integer' variable type now, permitting existing parameters defined by GDB proper, such as `listsize', to be accessed from Scheme code. With these changes in place it should be trivial for a Scheme or Python programmer to expand the syntax of the `make-parameter' command and the `gdb.Parameter' class initializer to have arbitrary extra literals along with their internal representation supplied. Update the testsuite accordingly. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-19 21:15:56 +00:00
/* Extra literals, such as `unlimited', accepted in lieu of a number. */
const literal_def *extra_literals;
/* The value of the parameter. */
union parmpy_variable value;
/* For an enum command, the possible values. The vector is
allocated with xmalloc, as is each element. It is
NULL-terminated. */
const char **enumeration;
};
gdb/python: add type traits check for all PyObject sub-classes All of our custom Python types are created as structs, like this: struct some_new_type : public PyObject { ... various fields ... }; Then instances of this struct are created by calling PyObject_New, either directly within GDB's C++ code, or within Python when a user's Python script creates an instance of that class. The problem is that Python is written in C, and PyObject_New doesn't call any constructors for `some_new_type`, nor for any of the fields within `some_new_type`. If `some_new_type` is Plain Old Data (POD), then this is fine. Or, to be more C++ specific, if `some_new_type` is trivially default constructable, then we're fine. But if a field within `some_new_type` has a non-trivial constructor, then we're in trouble as that constructor will never be run. An example of a problematic field type is frame_info_ptr. The constructor for this type registers the new object with a central management object, recording the `this` pointer, using this type within `some_new_type` will not work as expected; frame invalidation will not show up within the frame_info_ptr as you might expect. And so, this type trait exists. Whenever a struct is created to define a new Python type we should add a line like: static_assert (gdb::is_python_allocatable_v<some_new_type>); This will fail if any field of `some_new_type` are unsuitable for this use. We don't actually check is_trivially_default_constructible here. Some types, e.g. ui_file_style::color, have non-trivial (or no default) constructors, but are still safe to use within `some_new_type` because their constructors just initialise data fields; there's nothing "special" that the constructor does that cannot be achieved by assigning the fields after creation with PyObject_New. What actually matters is that the type is trivially destructible (Python won't call C++ destructors, so destructors with side effects, like deregistering from a list, would be skipped) and trivially copyable (Python may copy objects with memcpy). Types like frame_info_ptr, whose constructors and destructors have side effects such as registering with a central management object, will be caught because they are neither trivially destructible nor trivially copyable. Simple POD types like ui_file_style are trivially destructible and copyable, so pass this trait. This commit adds the new type trait, and makes use of it in all cases but one, pending_frame_object in python/py-unwind.c, has a field of type frame_info_ptr, which is currently broken. This will be fixed, and the static_assert added, in the next commit. Approved-By: Tom Tromey <tom@tromey.com>
2026-05-14 09:39:57 +01:00
static_assert (gdb::is_python_allocatable_v<parmpy_object>);
gdb: Introduce setting construct within cmd_list_element cmd_list_element can contain a pointer to data that can be set and / or shown. This is achieved with the void* VAR member which points to the data that can be accessed, while the VAR_TYPE member (of type enum var_types) indicates how to interpret the data pointed to. With this pattern, the user of the cmd_list_element needs to know what is the storage type associated with a given VAR_TYPES in order to do the proper casting. No automatic safeguard is available to prevent miss-use of the pointer. Client code typically looks something like: switch (c->var_type) { case var_zuinteger: unsigned int v = *(unsigned int*) c->var; ... break; case var_boolean: bool v = *(bool *) c->var; ... break; ... } This patch proposes to add an abstraction around the var_types and void* pointer pair. The abstraction is meant to prevent the user from having to handle the cast and verify that the data is read or written as a type that is coherent with the setting's var_type. This is achieved by introducing the struct setting which exposes a set of templated get / set member functions. The template parameter is the type of the variable that holds the referred variable. Using those accessors allows runtime checks to be inserted in order to ensure that the data pointed to has the expected type. For example, instantiating the member functions with bool will yield something similar to: const bool &get<bool> () const { gdb_assert (m_var_type == var_boolean); gdb_assert (m_var != nullptr); return *static_cast<bool *> (m_var); } void set<bool> (const bool &var) { gdb_assert (m_var_type == var_boolean); gdb_assert (m_var != nullptr); *static_cast<bool *> (m_var) = var; } Using the new abstraction, our initial example becomes: switch (c->var_type) { case var_zuinteger: unsigned int v = c->var->get<unsigned int> (); ... break; case var_boolean: bool v = c->var->get<bool> (); ... break; ... } While the call site is still similar, the introduction of runtime checks help ensure correct usage of the data. In order to avoid turning the bulk of add_setshow_cmd_full into a templated function, and following a suggestion from Pedro Alves, a setting can be constructed from a pre validated type erased reference to a variable. This is what setting::erased_args is used for. Introducing an opaque abstraction to describe a setting will also make it possible to use callbacks to retrieve or set the value of the setting on the fly instead of pointing to a static chunk of memory. This will be done added in a later commit. Given that a cmd_list_element may or may not reference a setting, the VAR and VAR_TYPES members of the struct are replaced with a gdb::optional<setting> named VAR. Few internal function signatures have been modified to take into account this new abstraction: -The functions value_from_setting, str_value_from_setting and get_setshow_command_value_string used to have a 'cmd_list_element *' parameter but only used it for the VAR and VAR_TYPE member. They now take a 'const setting &' parameter instead. - Similarly, the 'void *' and a 'enum var_types' parameters of pascm_param_value and gdbpy_parameter_value have been replaced with a 'const setting &' parameter. No user visible change is expected after this patch. Tested on GNU/Linux x86_64, with no regression noticed. Co-authored-by: Simon Marchi <simon.marchi@polymtl.ca> Change-Id: Ie1d08c3ceb8b30b3d7bf1efe036eb8acffcd2f34
2021-09-13 22:32:19 +01:00
/* Wraps a setting around an existing parmpy_object. This abstraction
is used to manipulate the value in S->VALUE in a type safe manner using
the setting interface. */
static setting
make_setting (parmpy_object *s)
{
GDB: Allow arbitrary keywords in integer set commands Rather than just `unlimited' allow the integer set commands (or command options) to define arbitrary keywords for the user to use, removing hardcoded arrangements for the `unlimited' keyword. Remove the confusingly named `var_zinteger', `var_zuinteger' and `var_zuinteger_unlimited' `set'/`show' command variable types redefining them in terms of `var_uinteger', `var_integer' and `var_pinteger', which have the range of [0;UINT_MAX], [INT_MIN;INT_MAX], and [0;INT_MAX] each. Following existing practice `var_pinteger' allows extra negative values to be used, however unlike `var_zuinteger_unlimited' any number of such values can be defined rather than just `-1'. The "p" in `var_pinteger' stands for "positive", for the lack of a more appropriate unambiguous letter, even though 0 obviously is not positive; "n" would be confusing as to whether it stands for "non-negative" or "negative". Add a new structure, `literal_def', the entries of which define extra keywords allowed for a command and numerical values they correspond to. Those values are not verified against the basic range supported by the underlying variable type, allowing extra values to be allowed outside that range, which may or may not be individually made visible to the user. An optional value translation is possible with the structure to follow the existing practice for some commands where user-entered 0 is internally translated to UINT_MAX or INT_MAX. Such translation can now be arbitrary. Literals defined by this structure are automatically used for completion as necessary. So for example: const literal_def integer_unlimited_literals[] = { { "unlimited", INT_MAX, 0 }, { nullptr } }; defines an extra `unlimited' keyword and a user-visible 0 value, both of which get translated to INT_MAX for the setting to be used with. Similarly: const literal_def zuinteger_unlimited_literals[] = { { "unlimited", -1, -1 }, { nullptr } }; defines the same keyword and a corresponding user-visible -1 value that is used for the requested setting. If the last member were omitted (or set to `{}') here, then only the keyword would be allowed for the user to enter and while -1 would still be used internally trying to enter it as a part of a command would result in an "integer -1 out of range" error. Use said error message in all cases (citing the invalid value requested) replacing "only -1 is allowed to set as unlimited" previously used for `var_zuinteger_unlimited' settings only rather than propagating it to `var_pinteger' type. It could only be used for the specific case where a single extra `unlimited' keyword was defined standing for -1 and the use of numeric equivalents is discouraged anyway as it is for historical reasons only that they expose GDB internals, confusingly different across variable types. Similarly update the "must be >= -1" Guile error message. Redefine Guile and Python parameter types in terms of the new variable types and interpret extra keywords as Scheme keywords and Python strings used to communicate corresponding parameter values. Do not add a new PARAM_INTEGER Guile parameter type, however do handle the `var_integer' variable type now, permitting existing parameters defined by GDB proper, such as `listsize', to be accessed from Scheme code. With these changes in place it should be trivial for a Scheme or Python programmer to expand the syntax of the `make-parameter' command and the `gdb.Parameter' class initializer to have arbitrary extra literals along with their internal representation supplied. Update the testsuite accordingly. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-19 21:15:56 +00:00
enum var_types type = s->type;
if (var_type_uses<bool> (type))
return setting (type, &s->value.boolval);
else if (var_type_uses<int> (type))
return setting (type, &s->value.intval, s->extra_literals);
else if (var_type_uses<auto_boolean> (type))
return setting (type, &s->value.autoboolval);
else if (var_type_uses<unsigned int> (type))
return setting (type, &s->value.uintval, s->extra_literals);
else if (var_type_uses<std::string> (type))
return setting (type, s->value.stringval);
else if (var_type_uses<const char *> (type))
return setting (type, &s->value.cstringval);
else if (var_type_uses<ui_file_style::color> (s->type))
return setting (s->type, &s->value.color);
gdb: Introduce setting construct within cmd_list_element cmd_list_element can contain a pointer to data that can be set and / or shown. This is achieved with the void* VAR member which points to the data that can be accessed, while the VAR_TYPE member (of type enum var_types) indicates how to interpret the data pointed to. With this pattern, the user of the cmd_list_element needs to know what is the storage type associated with a given VAR_TYPES in order to do the proper casting. No automatic safeguard is available to prevent miss-use of the pointer. Client code typically looks something like: switch (c->var_type) { case var_zuinteger: unsigned int v = *(unsigned int*) c->var; ... break; case var_boolean: bool v = *(bool *) c->var; ... break; ... } This patch proposes to add an abstraction around the var_types and void* pointer pair. The abstraction is meant to prevent the user from having to handle the cast and verify that the data is read or written as a type that is coherent with the setting's var_type. This is achieved by introducing the struct setting which exposes a set of templated get / set member functions. The template parameter is the type of the variable that holds the referred variable. Using those accessors allows runtime checks to be inserted in order to ensure that the data pointed to has the expected type. For example, instantiating the member functions with bool will yield something similar to: const bool &get<bool> () const { gdb_assert (m_var_type == var_boolean); gdb_assert (m_var != nullptr); return *static_cast<bool *> (m_var); } void set<bool> (const bool &var) { gdb_assert (m_var_type == var_boolean); gdb_assert (m_var != nullptr); *static_cast<bool *> (m_var) = var; } Using the new abstraction, our initial example becomes: switch (c->var_type) { case var_zuinteger: unsigned int v = c->var->get<unsigned int> (); ... break; case var_boolean: bool v = c->var->get<bool> (); ... break; ... } While the call site is still similar, the introduction of runtime checks help ensure correct usage of the data. In order to avoid turning the bulk of add_setshow_cmd_full into a templated function, and following a suggestion from Pedro Alves, a setting can be constructed from a pre validated type erased reference to a variable. This is what setting::erased_args is used for. Introducing an opaque abstraction to describe a setting will also make it possible to use callbacks to retrieve or set the value of the setting on the fly instead of pointing to a static chunk of memory. This will be done added in a later commit. Given that a cmd_list_element may or may not reference a setting, the VAR and VAR_TYPES members of the struct are replaced with a gdb::optional<setting> named VAR. Few internal function signatures have been modified to take into account this new abstraction: -The functions value_from_setting, str_value_from_setting and get_setshow_command_value_string used to have a 'cmd_list_element *' parameter but only used it for the VAR and VAR_TYPE member. They now take a 'const setting &' parameter instead. - Similarly, the 'void *' and a 'enum var_types' parameters of pascm_param_value and gdbpy_parameter_value have been replaced with a 'const setting &' parameter. No user visible change is expected after this patch. Tested on GNU/Linux x86_64, with no regression noticed. Co-authored-by: Simon Marchi <simon.marchi@polymtl.ca> Change-Id: Ie1d08c3ceb8b30b3d7bf1efe036eb8acffcd2f34
2021-09-13 22:32:19 +01:00
else
gdb_assert_not_reached ("unhandled var type");
}
extern PyTypeObject parmpy_object_type;
/* Some handy string constants. */
static PyObject *set_doc_cst;
static PyObject *show_doc_cst;
/* Get an attribute. */
static PyObject *
get_attr (PyObject *obj, PyObject *attr_name)
{
if (PyUnicode_Check (attr_name)
Add support for Python 3. * NEWS: Mention Python 3 support. * varobj.c (value_get_print_value): Use python_string_to_target_string. * python/py-block.c: Use PyVarObject_HEAD_INIT in initialization of type objects. * python/py-breakpoint.c: Ditto. * python/py-cmd.c: Ditto. * python/py-event.c: Ditto. * python/py-event.h: Ditto. * python/py-evtregistry.c: Ditto. * python/py-finishbreakpoint.c: Ditto. * python/py-frame.c: Ditto. * python/py-function.c: Ditto. * python/py-infthread.c: Ditto. * python/py-lazy-string.c: Ditto. * python/py-progspace.c: Ditto. * /python/py-symbol.c: Ditto. * python/py-evts.c: (gdbpy_initialize_py_events): Add module initialization for Python 3. * python/py-inferior.c: Use PyVarObject_HEAD_INIT in initialization of type objects. (infpy_read_memory): Return memoryview object if Python 3. (infpy_write_memory): Use "s*" operand parsing code for Python 3. (infpy_search_memory): Ditto. (get_buffer): New function for Python 3. * python/py-objfile.c: Use PyVarObject_HEAD_INIT in initialization of type objects. (objfpy_dealloc): Use Py_TYPE to call tp_free. * python/py-param.c: Use PyVarObject_HEAD_INIT in initialization of type objects. (get_attr): Use PyUnicode_CompareWithASCIIString if Python 3. (set_attr): Ditto. * python/py-prettyprint.c (print_string_repr): use PyBytes methods instead of PyString methods if Python 3. (print_children): Skip push_dummy_python_frame call if Python 3. * python/py-symtab.c: Use PyVarObject_HEAD_INIT in initialization of type objects. (salpy_dealloc): Use Py_TYPE to call tp_free. * python/py-type.c: Use PyVarObject_HEAD_INIT in initialization of type objects. (field_dealloc): Use Py_TYPE to call tp_free. (typy_dealloc): Ditto. (type_object_as_number): Adjust struct initializations for differences in layout for Python 2 vs. Python 3. * python/py-utils.c (python_string_to_unicode): Omit non-Unicode string case for Python 3. (unicode_to_encoded_python_string): Shorten code (no functional change). (python_string_to_target_python_string): Comment that in Python 3 returned value is a Python "bytes" type. (gdbpy_is_string): Omit non-Unicode string check in Python 3. (gdb_py_object_from_longest): Omit non-long integer case in Python 3. (gdb_py_object_from_ulongest): Ditto. * python/py-value.c: Use PyVarObject_HEAD_INIT in initialization of type objects. (valpy_dealloc): Use Py_TYPE to call tp_free. (valpy_int): Omit function if Python 3. (convert_value_from_python): Use "%S" format (Python object as a string) if Python 3. (value_object_as_number): Adjust struct initializations for differences in layout for Python 2 vs. Python 3. * python/python-config.py: Adjust syntax for Python 3 compatibility. Include "sys.abiflags" string as part of python library name, if that attribute exists (Python 3). * python/python-internal.h (IS_PY3): Define if Python 3. (Py_TPFLAGS_HAVE_ITER, Py_TPFLAGS_CHECKTYPES): Define with placeholder value if Python 3. (PyInt_Check, PyInt_FromLong, PyInt_AsLong, PyString_FromString, PyString_Decode, PyString_FromFormat, PyString_Check): Define as analogous Python 3 API function if Python 3. (PyVarObject_HEAD_INIT): Define if not already defined. (Py_TYPE): Ditto. * python/python.c (eval_python_command): Omit Py_FlushLine call if Python 3. Check return values of all Python API calls for error. Supply dummy "python" and "python-interactive" commands if Python initialization failed. (_initialize_python): Convert argc to wchar_t** if Python 3. Add module initialization for Python 3. (finish_python_initialization): Pass wchar_t * argument to PySys_SetPath if Python 3. * python/lib/gdb/__init__.py: Define "reload" if Python 3. (_GdbFile): New class for common output file behavior. (GdbOutFile): Subclass from _GdbFile. (GdbOutputErrorFile): Ditto. (auto_load_packages): Adjust syntax for Python 3 compatibility. * python/lib/gdb/printing.py: Define basestr and int if Python 3. * python/lib/gdb/prompt.py: Use sorted() function rather than sort() method. * python/lib/gdb/command/explore.py: Define raw_input if Python 3. Adjust syntax for Python 3 compatibility. * python/lib/gdb/command/pretty_printers.py: Use sorted() function rather than sort() method. Adjust syntax for Python 3 compatibility. * python/lib/gdb/command/type_printers.py: Ditto. * doc/gdb.texinfo (Inferior.read_memory): Mention that the return value is a memoryview object if Python 3.
2012-12-12 16:47:30 +00:00
&& ! PyUnicode_CompareWithASCIIString (attr_name, "value"))
{
parmpy_object *self = (parmpy_object *) obj;
gdb: Introduce setting construct within cmd_list_element cmd_list_element can contain a pointer to data that can be set and / or shown. This is achieved with the void* VAR member which points to the data that can be accessed, while the VAR_TYPE member (of type enum var_types) indicates how to interpret the data pointed to. With this pattern, the user of the cmd_list_element needs to know what is the storage type associated with a given VAR_TYPES in order to do the proper casting. No automatic safeguard is available to prevent miss-use of the pointer. Client code typically looks something like: switch (c->var_type) { case var_zuinteger: unsigned int v = *(unsigned int*) c->var; ... break; case var_boolean: bool v = *(bool *) c->var; ... break; ... } This patch proposes to add an abstraction around the var_types and void* pointer pair. The abstraction is meant to prevent the user from having to handle the cast and verify that the data is read or written as a type that is coherent with the setting's var_type. This is achieved by introducing the struct setting which exposes a set of templated get / set member functions. The template parameter is the type of the variable that holds the referred variable. Using those accessors allows runtime checks to be inserted in order to ensure that the data pointed to has the expected type. For example, instantiating the member functions with bool will yield something similar to: const bool &get<bool> () const { gdb_assert (m_var_type == var_boolean); gdb_assert (m_var != nullptr); return *static_cast<bool *> (m_var); } void set<bool> (const bool &var) { gdb_assert (m_var_type == var_boolean); gdb_assert (m_var != nullptr); *static_cast<bool *> (m_var) = var; } Using the new abstraction, our initial example becomes: switch (c->var_type) { case var_zuinteger: unsigned int v = c->var->get<unsigned int> (); ... break; case var_boolean: bool v = c->var->get<bool> (); ... break; ... } While the call site is still similar, the introduction of runtime checks help ensure correct usage of the data. In order to avoid turning the bulk of add_setshow_cmd_full into a templated function, and following a suggestion from Pedro Alves, a setting can be constructed from a pre validated type erased reference to a variable. This is what setting::erased_args is used for. Introducing an opaque abstraction to describe a setting will also make it possible to use callbacks to retrieve or set the value of the setting on the fly instead of pointing to a static chunk of memory. This will be done added in a later commit. Given that a cmd_list_element may or may not reference a setting, the VAR and VAR_TYPES members of the struct are replaced with a gdb::optional<setting> named VAR. Few internal function signatures have been modified to take into account this new abstraction: -The functions value_from_setting, str_value_from_setting and get_setshow_command_value_string used to have a 'cmd_list_element *' parameter but only used it for the VAR and VAR_TYPE member. They now take a 'const setting &' parameter instead. - Similarly, the 'void *' and a 'enum var_types' parameters of pascm_param_value and gdbpy_parameter_value have been replaced with a 'const setting &' parameter. No user visible change is expected after this patch. Tested on GNU/Linux x86_64, with no regression noticed. Co-authored-by: Simon Marchi <simon.marchi@polymtl.ca> Change-Id: Ie1d08c3ceb8b30b3d7bf1efe036eb8acffcd2f34
2021-09-13 22:32:19 +01:00
return gdbpy_parameter_value (make_setting (self));
}
return PyObject_GenericGetAttr (obj, attr_name);
}
gdb/ * python/py-breakpoint.c (bppy_set_condition): New comment. * python/py-cmd.c (cmdpy_function): Call also gdbpy_print_stack for failed PyUnicode_Decode. (cmdpy_completer): Skip element for failed python_string_to_host_string. (cmdpy_init): Return -1 on failed python_string_to_host_string. * python/py-frame.c (frapy_read_var): Extend the function comment. * python/py-function.c (fnpy_init): Return -1 on failed python_string_to_host_string. * python/py-inferior.c (infpy_read_memory, infpy_write_memory): Extend the function comment. (infpy_search_memory): Extend the function comment. Remove the PyErr_SetString call on already set error state. * python/py-param.c (set_parameter_value): Extend the function comment. Return -1 on failed python_string_to_host_string, twice. (set_attr): Extend the function comment. (compute_enum_values): Extend the function comment. New variable back_to. Protect self->enumeration by BACK_TO cleanups. Return 0 on failed python_string_to_host_string. (get_doc_string): Call gdbpy_print_stack on failed python_string_to_host_string. (parmpy_init): Extend the function comment. * python/py-prettyprint.c (pretty_print_one_value): Likewise. (gdbpy_get_display_hint, print_children): Call gdbpy_print_stack on failed python_string_to_host_string. * python/py-value.c (valpy_new, valpy_getitem, valpy_call) (valpy_binop, valpy_richcompare): Extend the function comment. * python/python.c (struct python_env) <error_type, error_value, error_traceback>: New fields. (restore_python_env): Handle PyErr_Occurred. Call PyErr_Restore. (ensure_python_env): Call PyErr_Fetch. * varobj.c (update_dynamic_varobj_children): Call gdbpy_print_stack on failed convert_value_from_python. (value_get_print_value): Call gdbpy_print_stack on failed python_string_to_target_python_string. gdb/testsuite/ * gdb.python/py-error.exp: New file. * gdb.python/py-error.py: New file.
2010-10-13 13:24:40 +00:00
/* Set a parameter value from a Python value. Return 0 on success. Returns
-1 on error, with a python exception set. */
static int
set_parameter_value (parmpy_object *self, PyObject *value)
{
int cmp;
switch (self->type)
{
case var_string:
case var_string_noescape:
case var_optional_filename:
case var_filename:
if (! gdbpy_is_string (value)
&& (self->type == var_filename
|| value != Py_None))
{
PyErr_SetString (PyExc_RuntimeError,
_("String required for filename."));
return -1;
}
if (value == Py_None)
gdb: make string-like set show commands use std::string variable String-like settings (var_string, var_filename, var_optional_filename, var_string_noescape) currently take a pointer to a `char *` storage variable (typically global) that holds the setting's value. I'd like to "mordernize" this by changing them to use an std::string for storage. An obvious reason is that string operations on std::string are often easier to write than with C strings. And they avoid having to do any manual memory management. Another interesting reason is that, with `char *`, nullptr and an empty string often both have the same meaning of "no value". String settings are initially nullptr (unless initialized otherwise). But when doing "set foo" (where `foo` is a string setting), the setting now points to an empty string. For example, solib_search_path is nullptr at startup, but points to an empty string after doing "set solib-search-path". This leads to some code that needs to check for both to check for "no value". Or some code that converts back and forth between NULL and "" when getting or setting the value. I find this very error-prone, because it is very easy to forget one or the other. With std::string, we at least know that the variable is not "NULL". There is only one way of representing an empty string setting, that is with an empty string. I was wondering whether the distinction between NULL and "" would be important for some setting, but it doesn't seem so. If that ever happens, it would be more C++-y and self-descriptive to use optional<string> anyway. Actually, there's one spot where this distinction mattered, it's in init_history, for the test gdb.base/gdbinit-history.exp. init_history sets the history filename to the default ".gdb_history" if it sees that the setting was never set - if history_filename is nullptr. If history_filename is an empty string, it means the setting was explicitly cleared, so it leaves it as-is. With the change to std::string, this distinction doesn't exist anymore. This can be fixed by moving the code that chooses a good default value for history_filename to _initialize_top. This is ran before -ex commands are processed, so an -ex command can then clear that value if needed (what gdb.base/gdbinit-history.exp tests). Another small improvement, in my opinion is that we can now easily give string parameters initial values, by simply initializing the global variables, instead of xstrdup-ing it in the _initialize function. In Python and Guile, when registering a string-like parameter, we allocate (with new) an std::string that is owned by the param_smob (in Guile) and the parmpy_object (in Python) objects. This patch started by changing all relevant add_setshow_* commands to take an `std::string *` instead of a `char **` and fixing everything that failed to build. That includes of course all string setting variable and their uses. string_option_def now uses an std::string also, because there's a connection between options and settings (see add_setshow_cmds_for_options). The add_path function in source.c is really complex and twisted, I'd rather not try to change it to work on an std::string right now. Instead, I added an overload that copies the std:string to a `char *` and back. This means more copying, but this is not used in a hot path at all, so I think it is acceptable. Change-Id: I92c50a1bdd8307141cdbacb388248e4e4fc08c93 Co-authored-by: Lancelot SIX <lsix@lancelotsix.com>
2021-09-10 17:10:13 -04:00
self->value.stringval->clear ();
else
gdb/ * python/py-breakpoint.c (bppy_set_condition): New comment. * python/py-cmd.c (cmdpy_function): Call also gdbpy_print_stack for failed PyUnicode_Decode. (cmdpy_completer): Skip element for failed python_string_to_host_string. (cmdpy_init): Return -1 on failed python_string_to_host_string. * python/py-frame.c (frapy_read_var): Extend the function comment. * python/py-function.c (fnpy_init): Return -1 on failed python_string_to_host_string. * python/py-inferior.c (infpy_read_memory, infpy_write_memory): Extend the function comment. (infpy_search_memory): Extend the function comment. Remove the PyErr_SetString call on already set error state. * python/py-param.c (set_parameter_value): Extend the function comment. Return -1 on failed python_string_to_host_string, twice. (set_attr): Extend the function comment. (compute_enum_values): Extend the function comment. New variable back_to. Protect self->enumeration by BACK_TO cleanups. Return 0 on failed python_string_to_host_string. (get_doc_string): Call gdbpy_print_stack on failed python_string_to_host_string. (parmpy_init): Extend the function comment. * python/py-prettyprint.c (pretty_print_one_value): Likewise. (gdbpy_get_display_hint, print_children): Call gdbpy_print_stack on failed python_string_to_host_string. * python/py-value.c (valpy_new, valpy_getitem, valpy_call) (valpy_binop, valpy_richcompare): Extend the function comment. * python/python.c (struct python_env) <error_type, error_value, error_traceback>: New fields. (restore_python_env): Handle PyErr_Occurred. Call PyErr_Restore. (ensure_python_env): Call PyErr_Fetch. * varobj.c (update_dynamic_varobj_children): Call gdbpy_print_stack on failed convert_value_from_python. (value_get_print_value): Call gdbpy_print_stack on failed python_string_to_target_python_string. gdb/testsuite/ * gdb.python/py-error.exp: New file. * gdb.python/py-error.py: New file.
2010-10-13 13:24:40 +00:00
{
Use unique_xmalloc_ptr in Python code This changes some utility functions in the Python code to return unique_xmalloc_ptr, and then fixes up the callers. I chose unique_xmalloc_ptr rather than std::string because at a few call points the xmalloc'd string is released and ownership transferred elsewhere. This patch found a few existing memory leaks. For example, py-unwind.c called gdbpy_obj_to_string but never freed the result. Built and regression tested on the buildbot. 2016-11-09 Tom Tromey <tom@tromey.com> * varobj.h (varobj_get_display_hint): Change return type. * varobj.c (varobj_get_display_hint): Return unique_xmalloc_ptr. (varobj_value_get_print_value): Update. * python/python.c (gdbpy_before_prompt_hook, gdbpy_print_stack) (gdbpy_apply_type_printers): Update. * python/python-internal.h (unicode_to_target_string) (python_string_to_target_string, python_string_to_host_string) (gdbpy_obj_to_string, gdbpy_exception_to_string) (gdbpy_get_display_hint): Change return types. * python/py-varobj.c (py_varobj_iter_next): Update. * python/py-value.c (valpy_getitem, convert_value_from_python): Update. * python/py-utils.c (unicode_to_encoded_string) (unicode_to_target_string, python_string_to_target_string) (python_string_to_host_string, gdbpy_obj_to_string) (gdbpy_exception_to_string): Return unique_xmalloc_ptr. * python/py-unwind.c (pyuw_parse_register_id): Update. * python/py-type.c (typy_getitem): Update. * python/py-prettyprint.c (gdbpy_get_display_hint) (print_stack_unless_memory_error, print_children) (gdbpy_apply_val_pretty_printer): Update. * python/py-param.c (set_parameter_value): Update. (get_doc_string, call_doc_function): Return unique_xmalloc_ptr. (get_set_value, get_show_value, compute_enum_values, parmpy_init): Update. * python/py-infthread.c (thpy_set_name): Update. * python/py-function.c (fnpy_call, fnpy_init): Update. * python/py-framefilter.c (extract_sym): Change "name" to unique_xmalloc_ptr. (enumerate_args, enumerate_locals): Update. (py_print_frame): Use unique_xmalloc_ptr. * python/py-frame.c (frapy_read_var): Update. Remove cleanup. * python/py-cmd.c (cmdpy_function, cmdpy_completer, cmdpy_init): Update. * python/py-breakpoint.c (bppy_set_condition): Use unique_xmalloc_ptr. (bppy_init): Likewise. Remove cleanup. (local_setattro): Update. * mi/mi-cmd-var.c (print_varobj, mi_cmd_var_list_children) (varobj_update_one): Update.
2016-10-15 09:20:02 -06:00
gdb::unique_xmalloc_ptr<char>
string (python_string_to_host_string (value));
gdb/ * python/py-breakpoint.c (bppy_set_condition): New comment. * python/py-cmd.c (cmdpy_function): Call also gdbpy_print_stack for failed PyUnicode_Decode. (cmdpy_completer): Skip element for failed python_string_to_host_string. (cmdpy_init): Return -1 on failed python_string_to_host_string. * python/py-frame.c (frapy_read_var): Extend the function comment. * python/py-function.c (fnpy_init): Return -1 on failed python_string_to_host_string. * python/py-inferior.c (infpy_read_memory, infpy_write_memory): Extend the function comment. (infpy_search_memory): Extend the function comment. Remove the PyErr_SetString call on already set error state. * python/py-param.c (set_parameter_value): Extend the function comment. Return -1 on failed python_string_to_host_string, twice. (set_attr): Extend the function comment. (compute_enum_values): Extend the function comment. New variable back_to. Protect self->enumeration by BACK_TO cleanups. Return 0 on failed python_string_to_host_string. (get_doc_string): Call gdbpy_print_stack on failed python_string_to_host_string. (parmpy_init): Extend the function comment. * python/py-prettyprint.c (pretty_print_one_value): Likewise. (gdbpy_get_display_hint, print_children): Call gdbpy_print_stack on failed python_string_to_host_string. * python/py-value.c (valpy_new, valpy_getitem, valpy_call) (valpy_binop, valpy_richcompare): Extend the function comment. * python/python.c (struct python_env) <error_type, error_value, error_traceback>: New fields. (restore_python_env): Handle PyErr_Occurred. Call PyErr_Restore. (ensure_python_env): Call PyErr_Fetch. * varobj.c (update_dynamic_varobj_children): Call gdbpy_print_stack on failed convert_value_from_python. (value_get_print_value): Call gdbpy_print_stack on failed python_string_to_target_python_string. gdb/testsuite/ * gdb.python/py-error.exp: New file. * gdb.python/py-error.py: New file.
2010-10-13 13:24:40 +00:00
if (string == NULL)
return -1;
gdb: make string-like set show commands use std::string variable String-like settings (var_string, var_filename, var_optional_filename, var_string_noescape) currently take a pointer to a `char *` storage variable (typically global) that holds the setting's value. I'd like to "mordernize" this by changing them to use an std::string for storage. An obvious reason is that string operations on std::string are often easier to write than with C strings. And they avoid having to do any manual memory management. Another interesting reason is that, with `char *`, nullptr and an empty string often both have the same meaning of "no value". String settings are initially nullptr (unless initialized otherwise). But when doing "set foo" (where `foo` is a string setting), the setting now points to an empty string. For example, solib_search_path is nullptr at startup, but points to an empty string after doing "set solib-search-path". This leads to some code that needs to check for both to check for "no value". Or some code that converts back and forth between NULL and "" when getting or setting the value. I find this very error-prone, because it is very easy to forget one or the other. With std::string, we at least know that the variable is not "NULL". There is only one way of representing an empty string setting, that is with an empty string. I was wondering whether the distinction between NULL and "" would be important for some setting, but it doesn't seem so. If that ever happens, it would be more C++-y and self-descriptive to use optional<string> anyway. Actually, there's one spot where this distinction mattered, it's in init_history, for the test gdb.base/gdbinit-history.exp. init_history sets the history filename to the default ".gdb_history" if it sees that the setting was never set - if history_filename is nullptr. If history_filename is an empty string, it means the setting was explicitly cleared, so it leaves it as-is. With the change to std::string, this distinction doesn't exist anymore. This can be fixed by moving the code that chooses a good default value for history_filename to _initialize_top. This is ran before -ex commands are processed, so an -ex command can then clear that value if needed (what gdb.base/gdbinit-history.exp tests). Another small improvement, in my opinion is that we can now easily give string parameters initial values, by simply initializing the global variables, instead of xstrdup-ing it in the _initialize function. In Python and Guile, when registering a string-like parameter, we allocate (with new) an std::string that is owned by the param_smob (in Guile) and the parmpy_object (in Python) objects. This patch started by changing all relevant add_setshow_* commands to take an `std::string *` instead of a `char **` and fixing everything that failed to build. That includes of course all string setting variable and their uses. string_option_def now uses an std::string also, because there's a connection between options and settings (see add_setshow_cmds_for_options). The add_path function in source.c is really complex and twisted, I'd rather not try to change it to work on an std::string right now. Instead, I added an overload that copies the std:string to a `char *` and back. This means more copying, but this is not used in a hot path at all, so I think it is acceptable. Change-Id: I92c50a1bdd8307141cdbacb388248e4e4fc08c93 Co-authored-by: Lancelot SIX <lsix@lancelotsix.com>
2021-09-10 17:10:13 -04:00
*self->value.stringval = string.get ();
gdb/ * python/py-breakpoint.c (bppy_set_condition): New comment. * python/py-cmd.c (cmdpy_function): Call also gdbpy_print_stack for failed PyUnicode_Decode. (cmdpy_completer): Skip element for failed python_string_to_host_string. (cmdpy_init): Return -1 on failed python_string_to_host_string. * python/py-frame.c (frapy_read_var): Extend the function comment. * python/py-function.c (fnpy_init): Return -1 on failed python_string_to_host_string. * python/py-inferior.c (infpy_read_memory, infpy_write_memory): Extend the function comment. (infpy_search_memory): Extend the function comment. Remove the PyErr_SetString call on already set error state. * python/py-param.c (set_parameter_value): Extend the function comment. Return -1 on failed python_string_to_host_string, twice. (set_attr): Extend the function comment. (compute_enum_values): Extend the function comment. New variable back_to. Protect self->enumeration by BACK_TO cleanups. Return 0 on failed python_string_to_host_string. (get_doc_string): Call gdbpy_print_stack on failed python_string_to_host_string. (parmpy_init): Extend the function comment. * python/py-prettyprint.c (pretty_print_one_value): Likewise. (gdbpy_get_display_hint, print_children): Call gdbpy_print_stack on failed python_string_to_host_string. * python/py-value.c (valpy_new, valpy_getitem, valpy_call) (valpy_binop, valpy_richcompare): Extend the function comment. * python/python.c (struct python_env) <error_type, error_value, error_traceback>: New fields. (restore_python_env): Handle PyErr_Occurred. Call PyErr_Restore. (ensure_python_env): Call PyErr_Fetch. * varobj.c (update_dynamic_varobj_children): Call gdbpy_print_stack on failed convert_value_from_python. (value_get_print_value): Call gdbpy_print_stack on failed python_string_to_target_python_string. gdb/testsuite/ * gdb.python/py-error.exp: New file. * gdb.python/py-error.py: New file.
2010-10-13 13:24:40 +00:00
}
break;
case var_enum:
{
int i;
if (! gdbpy_is_string (value))
{
PyErr_SetString (PyExc_RuntimeError,
_("ENUM arguments must be a string."));
return -1;
}
Use unique_xmalloc_ptr in Python code This changes some utility functions in the Python code to return unique_xmalloc_ptr, and then fixes up the callers. I chose unique_xmalloc_ptr rather than std::string because at a few call points the xmalloc'd string is released and ownership transferred elsewhere. This patch found a few existing memory leaks. For example, py-unwind.c called gdbpy_obj_to_string but never freed the result. Built and regression tested on the buildbot. 2016-11-09 Tom Tromey <tom@tromey.com> * varobj.h (varobj_get_display_hint): Change return type. * varobj.c (varobj_get_display_hint): Return unique_xmalloc_ptr. (varobj_value_get_print_value): Update. * python/python.c (gdbpy_before_prompt_hook, gdbpy_print_stack) (gdbpy_apply_type_printers): Update. * python/python-internal.h (unicode_to_target_string) (python_string_to_target_string, python_string_to_host_string) (gdbpy_obj_to_string, gdbpy_exception_to_string) (gdbpy_get_display_hint): Change return types. * python/py-varobj.c (py_varobj_iter_next): Update. * python/py-value.c (valpy_getitem, convert_value_from_python): Update. * python/py-utils.c (unicode_to_encoded_string) (unicode_to_target_string, python_string_to_target_string) (python_string_to_host_string, gdbpy_obj_to_string) (gdbpy_exception_to_string): Return unique_xmalloc_ptr. * python/py-unwind.c (pyuw_parse_register_id): Update. * python/py-type.c (typy_getitem): Update. * python/py-prettyprint.c (gdbpy_get_display_hint) (print_stack_unless_memory_error, print_children) (gdbpy_apply_val_pretty_printer): Update. * python/py-param.c (set_parameter_value): Update. (get_doc_string, call_doc_function): Return unique_xmalloc_ptr. (get_set_value, get_show_value, compute_enum_values, parmpy_init): Update. * python/py-infthread.c (thpy_set_name): Update. * python/py-function.c (fnpy_call, fnpy_init): Update. * python/py-framefilter.c (extract_sym): Change "name" to unique_xmalloc_ptr. (enumerate_args, enumerate_locals): Update. (py_print_frame): Use unique_xmalloc_ptr. * python/py-frame.c (frapy_read_var): Update. Remove cleanup. * python/py-cmd.c (cmdpy_function, cmdpy_completer, cmdpy_init): Update. * python/py-breakpoint.c (bppy_set_condition): Use unique_xmalloc_ptr. (bppy_init): Likewise. Remove cleanup. (local_setattro): Update. * mi/mi-cmd-var.c (print_varobj, mi_cmd_var_list_children) (varobj_update_one): Update.
2016-10-15 09:20:02 -06:00
gdb::unique_xmalloc_ptr<char>
str (python_string_to_host_string (value));
gdb/ * python/py-breakpoint.c (bppy_set_condition): New comment. * python/py-cmd.c (cmdpy_function): Call also gdbpy_print_stack for failed PyUnicode_Decode. (cmdpy_completer): Skip element for failed python_string_to_host_string. (cmdpy_init): Return -1 on failed python_string_to_host_string. * python/py-frame.c (frapy_read_var): Extend the function comment. * python/py-function.c (fnpy_init): Return -1 on failed python_string_to_host_string. * python/py-inferior.c (infpy_read_memory, infpy_write_memory): Extend the function comment. (infpy_search_memory): Extend the function comment. Remove the PyErr_SetString call on already set error state. * python/py-param.c (set_parameter_value): Extend the function comment. Return -1 on failed python_string_to_host_string, twice. (set_attr): Extend the function comment. (compute_enum_values): Extend the function comment. New variable back_to. Protect self->enumeration by BACK_TO cleanups. Return 0 on failed python_string_to_host_string. (get_doc_string): Call gdbpy_print_stack on failed python_string_to_host_string. (parmpy_init): Extend the function comment. * python/py-prettyprint.c (pretty_print_one_value): Likewise. (gdbpy_get_display_hint, print_children): Call gdbpy_print_stack on failed python_string_to_host_string. * python/py-value.c (valpy_new, valpy_getitem, valpy_call) (valpy_binop, valpy_richcompare): Extend the function comment. * python/python.c (struct python_env) <error_type, error_value, error_traceback>: New fields. (restore_python_env): Handle PyErr_Occurred. Call PyErr_Restore. (ensure_python_env): Call PyErr_Fetch. * varobj.c (update_dynamic_varobj_children): Call gdbpy_print_stack on failed convert_value_from_python. (value_get_print_value): Call gdbpy_print_stack on failed python_string_to_target_python_string. gdb/testsuite/ * gdb.python/py-error.exp: New file. * gdb.python/py-error.py: New file.
2010-10-13 13:24:40 +00:00
if (str == NULL)
return -1;
for (i = 0; self->enumeration[i]; ++i)
if (streq (self->enumeration[i], str.get ()))
break;
if (! self->enumeration[i])
{
PyErr_SetString (PyExc_RuntimeError,
_("The value must be member of an enumeration."));
return -1;
}
self->value.cstringval = self->enumeration[i];
break;
}
case var_color:
{
if (gdbpy_is_color (value))
self->value.color = gdbpy_get_color (value);
else
{
PyErr_SetString (PyExc_RuntimeError,
_("color argument must be a gdb.Color object."));
return -1;
}
}
break;
case var_boolean:
if (! PyBool_Check (value))
{
PyErr_SetString (PyExc_RuntimeError,
_("A boolean argument is required."));
return -1;
}
cmp = PyObject_IsTrue (value);
if (cmp < 0)
return -1;
Change boolean options to bool instead of int This is for add_setshow_boolean_cmd as well as the gdb::option interface. gdb/ChangeLog: 2019-09-17 Christian Biesinger <cbiesinger@google.com> * ada-lang.c (ada_ignore_descriptive_types_p): Change to bool. (print_signatures): Likewise. (trust_pad_over_xvs): Likewise. * arch/aarch64-insn.c (aarch64_debug): Likewise. * arch/aarch64-insn.h (aarch64_debug): Likewise. * arm-linux-nat.c (arm_apcs_32): Likewise. * arm-linux-tdep.c (arm_apcs_32): Likewise. * arm-nbsd-nat.c (arm_apcs_32): Likewise. * arm-tdep.c (arm_debug): Likewise. (arm_apcs_32): Likewise. * auto-load.c (debug_auto_load): Likewise. (auto_load_gdb_scripts): Likewise. (global_auto_load): Likewise. (auto_load_local_gdbinit): Likewise. (auto_load_local_gdbinit_loaded): Likewise. * auto-load.h (global_auto_load): Likewise. (auto_load_local_gdbinit): Likewise. (auto_load_local_gdbinit_loaded): Likewise. * breakpoint.c (disconnected_dprintf): Likewise. (breakpoint_proceeded): Likewise. (automatic_hardware_breakpoints): Likewise. (always_inserted_mode): Likewise. (target_exact_watchpoints): Likewise. (_initialize_breakpoint): Update. * breakpoint.h (target_exact_watchpoints): Change to bool. * btrace.c (maint_btrace_pt_skip_pad): Likewise. * cli/cli-cmds.c (trace_commands): Likewise. * cli/cli-cmds.h (trace_commands): Likewise. * cli/cli-decode.c (add_setshow_boolean_cmd): Change int* argument to bool*. * cli/cli-logging.c (logging_overwrite): Change to bool. (logging_redirect): Likewise. (debug_redirect): Likewise. * cli/cli-option.h (option_def) <boolean>: Change return type to bool*. (struct boolean_option_def) <get_var_address_cb_>: Change return type to bool. <boolean_option_def>: Update. (struct flag_option_def): Change default type of Context to bool from int. <flag_option_def>: Change return type of var_address_cb_ to bool*. * cli/cli-setshow.c (do_set_command): Cast to bool* instead of int*. (get_setshow_command_value_string): Likewise. * cli/cli-style.c (cli_styling): Change to bool. (source_styling): Likewise. * cli/cli-style.h (source_styling): Likewise. (cli_styling): Likewise. * cli/cli-utils.h (struct qcs_flags) <quiet, cont, silent>: Change to bool. * command.h (var_types): Update comment. (add_setshow_boolean_cmd): Change int* var argument to bool*. * compile/compile-cplus-types.c (debug_compile_cplus_types): Change to bool. (debug_compile_cplus_scopes): Likewise. * compile/compile-internal.h (compile_debug): Likewise. * compile/compile.c (compile_debug): Likewise. (struct compile_options) <raw>: Likewise. * cp-support.c (catch_demangler_crashes): Likewise. * cris-tdep.c (usr_cmd_cris_version_valid): Likewise. (usr_cmd_cris_dwarf2_cfi): Likewise. * csky-tdep.c (csky_debug): Likewise. * darwin-nat.c (enable_mach_exceptions): Likewise. * dcache.c (dcache_enabled_p): Likewise. * defs.h (info_verbose): Likewise. * demangle.c (demangle): Likewise. (asm_demangle): Likewise. * dwarf-index-cache.c (debug_index_cache): Likewise. * dwarf2-frame.c (dwarf2_frame_unwinders_enabled_p): Likewise. * dwarf2-frame.h (dwarf2_frame_unwinders_enabled_p): Likewise. * dwarf2read.c (check_physname): Likewise. (use_deprecated_index_sections): Likewise. (dwarf_always_disassemble): Likewise. * eval.c (overload_resolution): Likewise. * event-top.c (set_editing_cmd_var): Likewise. (exec_done_display_p): Likewise. * event-top.h (set_editing_cmd_var): Likewise. (exec_done_display_p): Likewise. * exec.c (write_files): Likewise. * fbsd-nat.c (debug_fbsd_lwp): Likewise (debug_fbsd_nat): Likewise. * frame.h (struct frame_print_options) <print_raw_frame_arguments>: Likewise. (struct set_backtrace_options) <backtrace_past_main>: Likewise. <backtrace_past_entry> Likewise. * gdb-demangle.h (demangle): Likewise. (asm_demangle): Likewise. * gdb_bfd.c (bfd_sharing): Likewise. * gdbcore.h (write_files): Likewise. * gdbsupport/common-debug.c (show_debug_regs): Likewise. * gdbsupport/common-debug.h (show_debug_regs): Likewise. * gdbthread.h (print_thread_events): Likewise. * gdbtypes.c (opaque_type_resolution): Likewise. (strict_type_checking): Likewise. * gnu-nat.c (gnu_debug_flag): Likewise. * guile/scm-auto-load.c (auto_load_guile_scripts): Likewise. * guile/scm-param.c (pascm_variable): Add boolval. (add_setshow_generic): Update. (pascm_param_value): Update. (pascm_set_param_value_x): Update. * hppa-tdep.c (hppa_debug): Change to bool.. * infcall.c (may_call_functions_p): Likewise. (coerce_float_to_double_p): Likewise. (unwind_on_signal_p): Likewise. (unwind_on_terminating_exception_p): Likewise. * infcmd.c (startup_with_shell): Likewise. * inferior.c (print_inferior_events): Likewise. * inferior.h (startup_with_shell): Likewise. (print_inferior_events): Likewise. * infrun.c (step_stop_if_no_debug): Likewise. (detach_fork): Likewise. (debug_displaced): Likewise. (disable_randomization): Likewise. (non_stop): Likewise. (non_stop_1): Likewise. (observer_mode): Likewise. (observer_mode_1): Likewise. (set_observer_mode): Update. (sched_multi): Change to bool. * infrun.h (debug_displaced): Likewise. (sched_multi): Likewise. (step_stop_if_no_debug): Likewise. (non_stop): Likewise. (disable_randomization): Likewise. * linux-tdep.c (use_coredump_filter): Likewise. (dump_excluded_mappings): Likewise. * linux-thread-db.c (auto_load_thread_db): Likewise. (check_thread_db_on_load): Likewise. * main.c (captured_main_1): Update. * maint-test-options.c (struct test_options_opts) <flag_opt, xx1_opt, xx2_opt, boolean_opt>: Change to bool. * maint-test-settings.c (maintenance_test_settings_boolean): Likewise. * maint.c (maintenance_profile_p): Likewise. (per_command_time): Likewise. (per_command_space): Likewise. (per_command_symtab): Likewise. * memattr.c (inaccessible_by_default): Likewise. * mi/mi-main.c (mi_async): Likewise. (mi_async_1): Likewise. * mips-tdep.c (mips64_transfers_32bit_regs_p): Likewise. * nat/fork-inferior.h (startup_with_shell): Likewise. * nat/linux-namespaces.c (debug_linux_namespaces): Likewise. * nat/linux-namespaces.h (debug_linux_namespaces): Likewise. * nios2-tdep.c (nios2_debug): Likewise. * or1k-tdep.c (or1k_debug): Likewise. * parse.c (parser_debug): Likewise. * parser-defs.h (parser_debug): Likewise. * printcmd.c (print_symbol_filename): Likewise. * proc-api.c (procfs_trace): Likewise. * python/py-auto-load.c (auto_load_python_scripts): Likewise. * python/py-param.c (union parmpy_variable): Add "bool boolval" field. (set_parameter_value): Update. (add_setshow_generic): Update. * python/py-value.c (copy_py_bool_obj): Change argument from int* to bool*. * python/python.c (gdbpy_parameter_value): Cast to bool* instead of int*. * ravenscar-thread.c (ravenscar_task_support): Change to bool. * record-btrace.c (record_btrace_target::store_registers): Update. * record-full.c (record_full_memory_query): Change to bool. (record_full_stop_at_limit): Likewise. * record-full.h (record_full_memory_query): Likewise. * remote-notif.c (notif_debug): Likewise. * remote-notif.h (notif_debug): Likewise. * remote.c (use_range_stepping): Likewise. (interrupt_on_connect): Likewise. (remote_break): Likewise. * ser-tcp.c (tcp_auto_retry): Likewise. * ser-unix.c (serial_hwflow): Likewise. * skip.c (debug_skip): Likewise. * solib-aix.c (solib_aix_debug): Likewise. * spu-tdep.c (spu_stop_on_load_p): Likewise. (spu_auto_flush_cache_p): Likewise. * stack.c (struct backtrace_cmd_options) <full, no_filters, hide>: Likewise. (struct info_print_options) <quiet>: Likewise. * symfile-debug.c (debug_symfile): Likewise. * symfile.c (auto_solib_add): Likewise. (separate_debug_file_debug): Likewise. * symfile.h (auto_solib_add): Likewise. (separate_debug_file_debug): Likewise. * symtab.c (basenames_may_differ): Likewise. (struct filename_partial_match_opts) <dirname, basename>: Likewise. (struct info_print_options) <quiet, exclude_minsyms>: Likewise. (struct info_types_options) <quiet>: Likewise. * symtab.h (demangle): Likewise. (basenames_may_differ): Likewise. * target-dcache.c (stack_cache_enabled_1): Likewise. (code_cache_enabled_1): Likewise. * target.c (trust_readonly): Likewise. (may_write_registers): Likewise. (may_write_memory): Likewise. (may_insert_breakpoints): Likewise. (may_insert_tracepoints): Likewise. (may_insert_fast_tracepoints): Likewise. (may_stop): Likewise. (auto_connect_native_target): Likewise. (target_stop_and_wait): Update. (target_async_permitted): Change to bool. (target_async_permitted_1): Likewise. (may_write_registers_1): Likewise. (may_write_memory_1): Likewise. (may_insert_breakpoints_1): Likewise. (may_insert_tracepoints_1): Likewise. (may_insert_fast_tracepoints_1): Likewise. (may_stop_1): Likewise. * target.h (target_async_permitted): Likewise. (may_write_registers): Likewise. (may_write_memory): Likewise. (may_insert_breakpoints): Likewise. (may_insert_tracepoints): Likewise. (may_insert_fast_tracepoints): Likewise. (may_stop): Likewise. * thread.c (struct info_threads_opts) <show_global_ids>: Likewise. (make_thread_apply_all_options_def_group): Change argument from int* to bool*. (thread_apply_all_command): Update. (print_thread_events): Change to bool. * top.c (confirm): Likewise. (command_editing_p): Likewise. (history_expansion_p): Likewise. (write_history_p): Likewise. (info_verbose): Likewise. * top.h (confirm): Likewise. (history_expansion_p): Likewise. * tracepoint.c (disconnected_tracing): Likewise. (circular_trace_buffer): Likewise. * typeprint.c (print_methods): Likewise. (print_typedefs): Likewise. * utils.c (debug_timestamp): Likewise. (sevenbit_strings): Likewise. (pagination_enabled): Likewise. * utils.h (sevenbit_strings): Likewise. (pagination_enabled): Likewise. * valops.c (overload_resolution): Likewise. * valprint.h (struct value_print_options) <prettyformat_arrays, prettyformat_structs, vtblprint, unionprint, addressprint, objectprint, stop_print_at_null, print_array_indexes, deref_ref, static_field_print, pascal_static_field_print, raw, summary, symbol_print, finish_print>: Likewise. * windows-nat.c (new_console): Likewise. (cygwin_exceptions): Likewise. (new_group): Likewise. (debug_exec): Likewise. (debug_events): Likewise. (debug_memory): Likewise. (debug_exceptions): Likewise. (useshell): Likewise. * windows-tdep.c (maint_display_all_tib): Likewise. * xml-support.c (debug_xml): Likewise.
2019-09-14 15:36:58 -04:00
self->value.boolval = cmp;
break;
case var_auto_boolean:
if (! PyBool_Check (value) && value != Py_None)
{
PyErr_SetString (PyExc_RuntimeError,
_("A boolean or None is required"));
return -1;
}
if (value == Py_None)
self->value.autoboolval = AUTO_BOOLEAN_AUTO;
else
{
cmp = PyObject_IsTrue (value);
if (cmp < 0 )
return -1;
if (cmp == 1)
self->value.autoboolval = AUTO_BOOLEAN_TRUE;
else
self->value.autoboolval = AUTO_BOOLEAN_FALSE;
}
break;
case var_uinteger:
GDB: Allow arbitrary keywords in integer set commands Rather than just `unlimited' allow the integer set commands (or command options) to define arbitrary keywords for the user to use, removing hardcoded arrangements for the `unlimited' keyword. Remove the confusingly named `var_zinteger', `var_zuinteger' and `var_zuinteger_unlimited' `set'/`show' command variable types redefining them in terms of `var_uinteger', `var_integer' and `var_pinteger', which have the range of [0;UINT_MAX], [INT_MIN;INT_MAX], and [0;INT_MAX] each. Following existing practice `var_pinteger' allows extra negative values to be used, however unlike `var_zuinteger_unlimited' any number of such values can be defined rather than just `-1'. The "p" in `var_pinteger' stands for "positive", for the lack of a more appropriate unambiguous letter, even though 0 obviously is not positive; "n" would be confusing as to whether it stands for "non-negative" or "negative". Add a new structure, `literal_def', the entries of which define extra keywords allowed for a command and numerical values they correspond to. Those values are not verified against the basic range supported by the underlying variable type, allowing extra values to be allowed outside that range, which may or may not be individually made visible to the user. An optional value translation is possible with the structure to follow the existing practice for some commands where user-entered 0 is internally translated to UINT_MAX or INT_MAX. Such translation can now be arbitrary. Literals defined by this structure are automatically used for completion as necessary. So for example: const literal_def integer_unlimited_literals[] = { { "unlimited", INT_MAX, 0 }, { nullptr } }; defines an extra `unlimited' keyword and a user-visible 0 value, both of which get translated to INT_MAX for the setting to be used with. Similarly: const literal_def zuinteger_unlimited_literals[] = { { "unlimited", -1, -1 }, { nullptr } }; defines the same keyword and a corresponding user-visible -1 value that is used for the requested setting. If the last member were omitted (or set to `{}') here, then only the keyword would be allowed for the user to enter and while -1 would still be used internally trying to enter it as a part of a command would result in an "integer -1 out of range" error. Use said error message in all cases (citing the invalid value requested) replacing "only -1 is allowed to set as unlimited" previously used for `var_zuinteger_unlimited' settings only rather than propagating it to `var_pinteger' type. It could only be used for the specific case where a single extra `unlimited' keyword was defined standing for -1 and the use of numeric equivalents is discouraged anyway as it is for historical reasons only that they expose GDB internals, confusingly different across variable types. Similarly update the "must be >= -1" Guile error message. Redefine Guile and Python parameter types in terms of the new variable types and interpret extra keywords as Scheme keywords and Python strings used to communicate corresponding parameter values. Do not add a new PARAM_INTEGER Guile parameter type, however do handle the `var_integer' variable type now, permitting existing parameters defined by GDB proper, such as `listsize', to be accessed from Scheme code. With these changes in place it should be trivial for a Scheme or Python programmer to expand the syntax of the `make-parameter' command and the `gdb.Parameter' class initializer to have arbitrary extra literals along with their internal representation supplied. Update the testsuite accordingly. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-19 21:15:56 +00:00
case var_integer:
case var_pinteger:
{
GDB: Allow arbitrary keywords in integer set commands Rather than just `unlimited' allow the integer set commands (or command options) to define arbitrary keywords for the user to use, removing hardcoded arrangements for the `unlimited' keyword. Remove the confusingly named `var_zinteger', `var_zuinteger' and `var_zuinteger_unlimited' `set'/`show' command variable types redefining them in terms of `var_uinteger', `var_integer' and `var_pinteger', which have the range of [0;UINT_MAX], [INT_MIN;INT_MAX], and [0;INT_MAX] each. Following existing practice `var_pinteger' allows extra negative values to be used, however unlike `var_zuinteger_unlimited' any number of such values can be defined rather than just `-1'. The "p" in `var_pinteger' stands for "positive", for the lack of a more appropriate unambiguous letter, even though 0 obviously is not positive; "n" would be confusing as to whether it stands for "non-negative" or "negative". Add a new structure, `literal_def', the entries of which define extra keywords allowed for a command and numerical values they correspond to. Those values are not verified against the basic range supported by the underlying variable type, allowing extra values to be allowed outside that range, which may or may not be individually made visible to the user. An optional value translation is possible with the structure to follow the existing practice for some commands where user-entered 0 is internally translated to UINT_MAX or INT_MAX. Such translation can now be arbitrary. Literals defined by this structure are automatically used for completion as necessary. So for example: const literal_def integer_unlimited_literals[] = { { "unlimited", INT_MAX, 0 }, { nullptr } }; defines an extra `unlimited' keyword and a user-visible 0 value, both of which get translated to INT_MAX for the setting to be used with. Similarly: const literal_def zuinteger_unlimited_literals[] = { { "unlimited", -1, -1 }, { nullptr } }; defines the same keyword and a corresponding user-visible -1 value that is used for the requested setting. If the last member were omitted (or set to `{}') here, then only the keyword would be allowed for the user to enter and while -1 would still be used internally trying to enter it as a part of a command would result in an "integer -1 out of range" error. Use said error message in all cases (citing the invalid value requested) replacing "only -1 is allowed to set as unlimited" previously used for `var_zuinteger_unlimited' settings only rather than propagating it to `var_pinteger' type. It could only be used for the specific case where a single extra `unlimited' keyword was defined standing for -1 and the use of numeric equivalents is discouraged anyway as it is for historical reasons only that they expose GDB internals, confusingly different across variable types. Similarly update the "must be >= -1" Guile error message. Redefine Guile and Python parameter types in terms of the new variable types and interpret extra keywords as Scheme keywords and Python strings used to communicate corresponding parameter values. Do not add a new PARAM_INTEGER Guile parameter type, however do handle the `var_integer' variable type now, permitting existing parameters defined by GDB proper, such as `listsize', to be accessed from Scheme code. With these changes in place it should be trivial for a Scheme or Python programmer to expand the syntax of the `make-parameter' command and the `gdb.Parameter' class initializer to have arbitrary extra literals along with their internal representation supplied. Update the testsuite accordingly. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-19 21:15:56 +00:00
const literal_def *extra_literals = self->extra_literals;
enum tribool allowed = TRIBOOL_UNKNOWN;
enum var_types var_type = self->type;
std::string buffer = "";
size_t count = 0;
LONGEST val;
if (extra_literals != nullptr)
{
GDB: Allow arbitrary keywords in integer set commands Rather than just `unlimited' allow the integer set commands (or command options) to define arbitrary keywords for the user to use, removing hardcoded arrangements for the `unlimited' keyword. Remove the confusingly named `var_zinteger', `var_zuinteger' and `var_zuinteger_unlimited' `set'/`show' command variable types redefining them in terms of `var_uinteger', `var_integer' and `var_pinteger', which have the range of [0;UINT_MAX], [INT_MIN;INT_MAX], and [0;INT_MAX] each. Following existing practice `var_pinteger' allows extra negative values to be used, however unlike `var_zuinteger_unlimited' any number of such values can be defined rather than just `-1'. The "p" in `var_pinteger' stands for "positive", for the lack of a more appropriate unambiguous letter, even though 0 obviously is not positive; "n" would be confusing as to whether it stands for "non-negative" or "negative". Add a new structure, `literal_def', the entries of which define extra keywords allowed for a command and numerical values they correspond to. Those values are not verified against the basic range supported by the underlying variable type, allowing extra values to be allowed outside that range, which may or may not be individually made visible to the user. An optional value translation is possible with the structure to follow the existing practice for some commands where user-entered 0 is internally translated to UINT_MAX or INT_MAX. Such translation can now be arbitrary. Literals defined by this structure are automatically used for completion as necessary. So for example: const literal_def integer_unlimited_literals[] = { { "unlimited", INT_MAX, 0 }, { nullptr } }; defines an extra `unlimited' keyword and a user-visible 0 value, both of which get translated to INT_MAX for the setting to be used with. Similarly: const literal_def zuinteger_unlimited_literals[] = { { "unlimited", -1, -1 }, { nullptr } }; defines the same keyword and a corresponding user-visible -1 value that is used for the requested setting. If the last member were omitted (or set to `{}') here, then only the keyword would be allowed for the user to enter and while -1 would still be used internally trying to enter it as a part of a command would result in an "integer -1 out of range" error. Use said error message in all cases (citing the invalid value requested) replacing "only -1 is allowed to set as unlimited" previously used for `var_zuinteger_unlimited' settings only rather than propagating it to `var_pinteger' type. It could only be used for the specific case where a single extra `unlimited' keyword was defined standing for -1 and the use of numeric equivalents is discouraged anyway as it is for historical reasons only that they expose GDB internals, confusingly different across variable types. Similarly update the "must be >= -1" Guile error message. Redefine Guile and Python parameter types in terms of the new variable types and interpret extra keywords as Scheme keywords and Python strings used to communicate corresponding parameter values. Do not add a new PARAM_INTEGER Guile parameter type, however do handle the `var_integer' variable type now, permitting existing parameters defined by GDB proper, such as `listsize', to be accessed from Scheme code. With these changes in place it should be trivial for a Scheme or Python programmer to expand the syntax of the `make-parameter' command and the `gdb.Parameter' class initializer to have arbitrary extra literals along with their internal representation supplied. Update the testsuite accordingly. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-19 21:15:56 +00:00
gdb::unique_xmalloc_ptr<char>
str (python_string_to_host_string (value));
const char *s = str != nullptr ? str.get () : nullptr;
PyErr_Clear ();
for (const literal_def *l = extra_literals;
l->literal != nullptr;
l++, count++)
{
if (count != 0)
buffer += ", ";
buffer = buffer + "'" + l->literal + "'";
if (allowed == TRIBOOL_UNKNOWN
&& ((value == Py_None && streq ("unlimited", l->literal))
|| (s != nullptr && streq (s, l->literal))))
GDB: Allow arbitrary keywords in integer set commands Rather than just `unlimited' allow the integer set commands (or command options) to define arbitrary keywords for the user to use, removing hardcoded arrangements for the `unlimited' keyword. Remove the confusingly named `var_zinteger', `var_zuinteger' and `var_zuinteger_unlimited' `set'/`show' command variable types redefining them in terms of `var_uinteger', `var_integer' and `var_pinteger', which have the range of [0;UINT_MAX], [INT_MIN;INT_MAX], and [0;INT_MAX] each. Following existing practice `var_pinteger' allows extra negative values to be used, however unlike `var_zuinteger_unlimited' any number of such values can be defined rather than just `-1'. The "p" in `var_pinteger' stands for "positive", for the lack of a more appropriate unambiguous letter, even though 0 obviously is not positive; "n" would be confusing as to whether it stands for "non-negative" or "negative". Add a new structure, `literal_def', the entries of which define extra keywords allowed for a command and numerical values they correspond to. Those values are not verified against the basic range supported by the underlying variable type, allowing extra values to be allowed outside that range, which may or may not be individually made visible to the user. An optional value translation is possible with the structure to follow the existing practice for some commands where user-entered 0 is internally translated to UINT_MAX or INT_MAX. Such translation can now be arbitrary. Literals defined by this structure are automatically used for completion as necessary. So for example: const literal_def integer_unlimited_literals[] = { { "unlimited", INT_MAX, 0 }, { nullptr } }; defines an extra `unlimited' keyword and a user-visible 0 value, both of which get translated to INT_MAX for the setting to be used with. Similarly: const literal_def zuinteger_unlimited_literals[] = { { "unlimited", -1, -1 }, { nullptr } }; defines the same keyword and a corresponding user-visible -1 value that is used for the requested setting. If the last member were omitted (or set to `{}') here, then only the keyword would be allowed for the user to enter and while -1 would still be used internally trying to enter it as a part of a command would result in an "integer -1 out of range" error. Use said error message in all cases (citing the invalid value requested) replacing "only -1 is allowed to set as unlimited" previously used for `var_zuinteger_unlimited' settings only rather than propagating it to `var_pinteger' type. It could only be used for the specific case where a single extra `unlimited' keyword was defined standing for -1 and the use of numeric equivalents is discouraged anyway as it is for historical reasons only that they expose GDB internals, confusingly different across variable types. Similarly update the "must be >= -1" Guile error message. Redefine Guile and Python parameter types in terms of the new variable types and interpret extra keywords as Scheme keywords and Python strings used to communicate corresponding parameter values. Do not add a new PARAM_INTEGER Guile parameter type, however do handle the `var_integer' variable type now, permitting existing parameters defined by GDB proper, such as `listsize', to be accessed from Scheme code. With these changes in place it should be trivial for a Scheme or Python programmer to expand the syntax of the `make-parameter' command and the `gdb.Parameter' class initializer to have arbitrary extra literals along with their internal representation supplied. Update the testsuite accordingly. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-19 21:15:56 +00:00
{
val = l->use;
allowed = TRIBOOL_TRUE;
}
}
}
2011-01-26 20:53:45 +00:00
GDB: Allow arbitrary keywords in integer set commands Rather than just `unlimited' allow the integer set commands (or command options) to define arbitrary keywords for the user to use, removing hardcoded arrangements for the `unlimited' keyword. Remove the confusingly named `var_zinteger', `var_zuinteger' and `var_zuinteger_unlimited' `set'/`show' command variable types redefining them in terms of `var_uinteger', `var_integer' and `var_pinteger', which have the range of [0;UINT_MAX], [INT_MIN;INT_MAX], and [0;INT_MAX] each. Following existing practice `var_pinteger' allows extra negative values to be used, however unlike `var_zuinteger_unlimited' any number of such values can be defined rather than just `-1'. The "p" in `var_pinteger' stands for "positive", for the lack of a more appropriate unambiguous letter, even though 0 obviously is not positive; "n" would be confusing as to whether it stands for "non-negative" or "negative". Add a new structure, `literal_def', the entries of which define extra keywords allowed for a command and numerical values they correspond to. Those values are not verified against the basic range supported by the underlying variable type, allowing extra values to be allowed outside that range, which may or may not be individually made visible to the user. An optional value translation is possible with the structure to follow the existing practice for some commands where user-entered 0 is internally translated to UINT_MAX or INT_MAX. Such translation can now be arbitrary. Literals defined by this structure are automatically used for completion as necessary. So for example: const literal_def integer_unlimited_literals[] = { { "unlimited", INT_MAX, 0 }, { nullptr } }; defines an extra `unlimited' keyword and a user-visible 0 value, both of which get translated to INT_MAX for the setting to be used with. Similarly: const literal_def zuinteger_unlimited_literals[] = { { "unlimited", -1, -1 }, { nullptr } }; defines the same keyword and a corresponding user-visible -1 value that is used for the requested setting. If the last member were omitted (or set to `{}') here, then only the keyword would be allowed for the user to enter and while -1 would still be used internally trying to enter it as a part of a command would result in an "integer -1 out of range" error. Use said error message in all cases (citing the invalid value requested) replacing "only -1 is allowed to set as unlimited" previously used for `var_zuinteger_unlimited' settings only rather than propagating it to `var_pinteger' type. It could only be used for the specific case where a single extra `unlimited' keyword was defined standing for -1 and the use of numeric equivalents is discouraged anyway as it is for historical reasons only that they expose GDB internals, confusingly different across variable types. Similarly update the "must be >= -1" Guile error message. Redefine Guile and Python parameter types in terms of the new variable types and interpret extra keywords as Scheme keywords and Python strings used to communicate corresponding parameter values. Do not add a new PARAM_INTEGER Guile parameter type, however do handle the `var_integer' variable type now, permitting existing parameters defined by GDB proper, such as `listsize', to be accessed from Scheme code. With these changes in place it should be trivial for a Scheme or Python programmer to expand the syntax of the `make-parameter' command and the `gdb.Parameter' class initializer to have arbitrary extra literals along with their internal representation supplied. Update the testsuite accordingly. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-19 21:15:56 +00:00
if (allowed == TRIBOOL_UNKNOWN)
{
GDB: Allow arbitrary keywords in integer set commands Rather than just `unlimited' allow the integer set commands (or command options) to define arbitrary keywords for the user to use, removing hardcoded arrangements for the `unlimited' keyword. Remove the confusingly named `var_zinteger', `var_zuinteger' and `var_zuinteger_unlimited' `set'/`show' command variable types redefining them in terms of `var_uinteger', `var_integer' and `var_pinteger', which have the range of [0;UINT_MAX], [INT_MIN;INT_MAX], and [0;INT_MAX] each. Following existing practice `var_pinteger' allows extra negative values to be used, however unlike `var_zuinteger_unlimited' any number of such values can be defined rather than just `-1'. The "p" in `var_pinteger' stands for "positive", for the lack of a more appropriate unambiguous letter, even though 0 obviously is not positive; "n" would be confusing as to whether it stands for "non-negative" or "negative". Add a new structure, `literal_def', the entries of which define extra keywords allowed for a command and numerical values they correspond to. Those values are not verified against the basic range supported by the underlying variable type, allowing extra values to be allowed outside that range, which may or may not be individually made visible to the user. An optional value translation is possible with the structure to follow the existing practice for some commands where user-entered 0 is internally translated to UINT_MAX or INT_MAX. Such translation can now be arbitrary. Literals defined by this structure are automatically used for completion as necessary. So for example: const literal_def integer_unlimited_literals[] = { { "unlimited", INT_MAX, 0 }, { nullptr } }; defines an extra `unlimited' keyword and a user-visible 0 value, both of which get translated to INT_MAX for the setting to be used with. Similarly: const literal_def zuinteger_unlimited_literals[] = { { "unlimited", -1, -1 }, { nullptr } }; defines the same keyword and a corresponding user-visible -1 value that is used for the requested setting. If the last member were omitted (or set to `{}') here, then only the keyword would be allowed for the user to enter and while -1 would still be used internally trying to enter it as a part of a command would result in an "integer -1 out of range" error. Use said error message in all cases (citing the invalid value requested) replacing "only -1 is allowed to set as unlimited" previously used for `var_zuinteger_unlimited' settings only rather than propagating it to `var_pinteger' type. It could only be used for the specific case where a single extra `unlimited' keyword was defined standing for -1 and the use of numeric equivalents is discouraged anyway as it is for historical reasons only that they expose GDB internals, confusingly different across variable types. Similarly update the "must be >= -1" Guile error message. Redefine Guile and Python parameter types in terms of the new variable types and interpret extra keywords as Scheme keywords and Python strings used to communicate corresponding parameter values. Do not add a new PARAM_INTEGER Guile parameter type, however do handle the `var_integer' variable type now, permitting existing parameters defined by GDB proper, such as `listsize', to be accessed from Scheme code. With these changes in place it should be trivial for a Scheme or Python programmer to expand the syntax of the `make-parameter' command and the `gdb.Parameter' class initializer to have arbitrary extra literals along with their internal representation supplied. Update the testsuite accordingly. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-19 21:15:56 +00:00
val = PyLong_AsLongLong (value);
if (PyErr_Occurred ())
{
if (extra_literals == nullptr)
PyErr_SetString (PyExc_RuntimeError,
_("The value must be integer."));
else if (count > 1)
PyErr_SetString (PyExc_RuntimeError,
string_printf (_("integer or one of: %s"),
buffer.c_str ()).c_str ());
else
PyErr_SetString (PyExc_RuntimeError,
string_printf (_("integer or %s"),
buffer.c_str ()).c_str ());
return -1;
}
if (extra_literals != nullptr)
for (const literal_def *l = extra_literals;
l->literal != nullptr;
l++)
{
if (l->val.has_value () && val == *l->val)
{
allowed = TRIBOOL_TRUE;
val = l->use;
break;
}
else if (val == l->use)
allowed = TRIBOOL_FALSE;
}
}
if (allowed == TRIBOOL_UNKNOWN)
{
if (val > UINT_MAX || val < INT_MIN
|| (var_type == var_uinteger && val < 0)
|| (var_type == var_integer && val > INT_MAX)
|| (var_type == var_pinteger && val < 0)
|| (var_type == var_pinteger && val > INT_MAX))
allowed = TRIBOOL_FALSE;
}
GDB: Allow arbitrary keywords in integer set commands Rather than just `unlimited' allow the integer set commands (or command options) to define arbitrary keywords for the user to use, removing hardcoded arrangements for the `unlimited' keyword. Remove the confusingly named `var_zinteger', `var_zuinteger' and `var_zuinteger_unlimited' `set'/`show' command variable types redefining them in terms of `var_uinteger', `var_integer' and `var_pinteger', which have the range of [0;UINT_MAX], [INT_MIN;INT_MAX], and [0;INT_MAX] each. Following existing practice `var_pinteger' allows extra negative values to be used, however unlike `var_zuinteger_unlimited' any number of such values can be defined rather than just `-1'. The "p" in `var_pinteger' stands for "positive", for the lack of a more appropriate unambiguous letter, even though 0 obviously is not positive; "n" would be confusing as to whether it stands for "non-negative" or "negative". Add a new structure, `literal_def', the entries of which define extra keywords allowed for a command and numerical values they correspond to. Those values are not verified against the basic range supported by the underlying variable type, allowing extra values to be allowed outside that range, which may or may not be individually made visible to the user. An optional value translation is possible with the structure to follow the existing practice for some commands where user-entered 0 is internally translated to UINT_MAX or INT_MAX. Such translation can now be arbitrary. Literals defined by this structure are automatically used for completion as necessary. So for example: const literal_def integer_unlimited_literals[] = { { "unlimited", INT_MAX, 0 }, { nullptr } }; defines an extra `unlimited' keyword and a user-visible 0 value, both of which get translated to INT_MAX for the setting to be used with. Similarly: const literal_def zuinteger_unlimited_literals[] = { { "unlimited", -1, -1 }, { nullptr } }; defines the same keyword and a corresponding user-visible -1 value that is used for the requested setting. If the last member were omitted (or set to `{}') here, then only the keyword would be allowed for the user to enter and while -1 would still be used internally trying to enter it as a part of a command would result in an "integer -1 out of range" error. Use said error message in all cases (citing the invalid value requested) replacing "only -1 is allowed to set as unlimited" previously used for `var_zuinteger_unlimited' settings only rather than propagating it to `var_pinteger' type. It could only be used for the specific case where a single extra `unlimited' keyword was defined standing for -1 and the use of numeric equivalents is discouraged anyway as it is for historical reasons only that they expose GDB internals, confusingly different across variable types. Similarly update the "must be >= -1" Guile error message. Redefine Guile and Python parameter types in terms of the new variable types and interpret extra keywords as Scheme keywords and Python strings used to communicate corresponding parameter values. Do not add a new PARAM_INTEGER Guile parameter type, however do handle the `var_integer' variable type now, permitting existing parameters defined by GDB proper, such as `listsize', to be accessed from Scheme code. With these changes in place it should be trivial for a Scheme or Python programmer to expand the syntax of the `make-parameter' command and the `gdb.Parameter' class initializer to have arbitrary extra literals along with their internal representation supplied. Update the testsuite accordingly. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-19 21:15:56 +00:00
if (allowed == TRIBOOL_FALSE)
{
PyErr_SetString (PyExc_RuntimeError,
_("Range exceeded."));
return -1;
}
GDB: Allow arbitrary keywords in integer set commands Rather than just `unlimited' allow the integer set commands (or command options) to define arbitrary keywords for the user to use, removing hardcoded arrangements for the `unlimited' keyword. Remove the confusingly named `var_zinteger', `var_zuinteger' and `var_zuinteger_unlimited' `set'/`show' command variable types redefining them in terms of `var_uinteger', `var_integer' and `var_pinteger', which have the range of [0;UINT_MAX], [INT_MIN;INT_MAX], and [0;INT_MAX] each. Following existing practice `var_pinteger' allows extra negative values to be used, however unlike `var_zuinteger_unlimited' any number of such values can be defined rather than just `-1'. The "p" in `var_pinteger' stands for "positive", for the lack of a more appropriate unambiguous letter, even though 0 obviously is not positive; "n" would be confusing as to whether it stands for "non-negative" or "negative". Add a new structure, `literal_def', the entries of which define extra keywords allowed for a command and numerical values they correspond to. Those values are not verified against the basic range supported by the underlying variable type, allowing extra values to be allowed outside that range, which may or may not be individually made visible to the user. An optional value translation is possible with the structure to follow the existing practice for some commands where user-entered 0 is internally translated to UINT_MAX or INT_MAX. Such translation can now be arbitrary. Literals defined by this structure are automatically used for completion as necessary. So for example: const literal_def integer_unlimited_literals[] = { { "unlimited", INT_MAX, 0 }, { nullptr } }; defines an extra `unlimited' keyword and a user-visible 0 value, both of which get translated to INT_MAX for the setting to be used with. Similarly: const literal_def zuinteger_unlimited_literals[] = { { "unlimited", -1, -1 }, { nullptr } }; defines the same keyword and a corresponding user-visible -1 value that is used for the requested setting. If the last member were omitted (or set to `{}') here, then only the keyword would be allowed for the user to enter and while -1 would still be used internally trying to enter it as a part of a command would result in an "integer -1 out of range" error. Use said error message in all cases (citing the invalid value requested) replacing "only -1 is allowed to set as unlimited" previously used for `var_zuinteger_unlimited' settings only rather than propagating it to `var_pinteger' type. It could only be used for the specific case where a single extra `unlimited' keyword was defined standing for -1 and the use of numeric equivalents is discouraged anyway as it is for historical reasons only that they expose GDB internals, confusingly different across variable types. Similarly update the "must be >= -1" Guile error message. Redefine Guile and Python parameter types in terms of the new variable types and interpret extra keywords as Scheme keywords and Python strings used to communicate corresponding parameter values. Do not add a new PARAM_INTEGER Guile parameter type, however do handle the `var_integer' variable type now, permitting existing parameters defined by GDB proper, such as `listsize', to be accessed from Scheme code. With these changes in place it should be trivial for a Scheme or Python programmer to expand the syntax of the `make-parameter' command and the `gdb.Parameter' class initializer to have arbitrary extra literals along with their internal representation supplied. Update the testsuite accordingly. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-19 21:15:56 +00:00
if (self->type == var_uinteger)
self->value.uintval = (unsigned) val;
else
GDB: Allow arbitrary keywords in integer set commands Rather than just `unlimited' allow the integer set commands (or command options) to define arbitrary keywords for the user to use, removing hardcoded arrangements for the `unlimited' keyword. Remove the confusingly named `var_zinteger', `var_zuinteger' and `var_zuinteger_unlimited' `set'/`show' command variable types redefining them in terms of `var_uinteger', `var_integer' and `var_pinteger', which have the range of [0;UINT_MAX], [INT_MIN;INT_MAX], and [0;INT_MAX] each. Following existing practice `var_pinteger' allows extra negative values to be used, however unlike `var_zuinteger_unlimited' any number of such values can be defined rather than just `-1'. The "p" in `var_pinteger' stands for "positive", for the lack of a more appropriate unambiguous letter, even though 0 obviously is not positive; "n" would be confusing as to whether it stands for "non-negative" or "negative". Add a new structure, `literal_def', the entries of which define extra keywords allowed for a command and numerical values they correspond to. Those values are not verified against the basic range supported by the underlying variable type, allowing extra values to be allowed outside that range, which may or may not be individually made visible to the user. An optional value translation is possible with the structure to follow the existing practice for some commands where user-entered 0 is internally translated to UINT_MAX or INT_MAX. Such translation can now be arbitrary. Literals defined by this structure are automatically used for completion as necessary. So for example: const literal_def integer_unlimited_literals[] = { { "unlimited", INT_MAX, 0 }, { nullptr } }; defines an extra `unlimited' keyword and a user-visible 0 value, both of which get translated to INT_MAX for the setting to be used with. Similarly: const literal_def zuinteger_unlimited_literals[] = { { "unlimited", -1, -1 }, { nullptr } }; defines the same keyword and a corresponding user-visible -1 value that is used for the requested setting. If the last member were omitted (or set to `{}') here, then only the keyword would be allowed for the user to enter and while -1 would still be used internally trying to enter it as a part of a command would result in an "integer -1 out of range" error. Use said error message in all cases (citing the invalid value requested) replacing "only -1 is allowed to set as unlimited" previously used for `var_zuinteger_unlimited' settings only rather than propagating it to `var_pinteger' type. It could only be used for the specific case where a single extra `unlimited' keyword was defined standing for -1 and the use of numeric equivalents is discouraged anyway as it is for historical reasons only that they expose GDB internals, confusingly different across variable types. Similarly update the "must be >= -1" Guile error message. Redefine Guile and Python parameter types in terms of the new variable types and interpret extra keywords as Scheme keywords and Python strings used to communicate corresponding parameter values. Do not add a new PARAM_INTEGER Guile parameter type, however do handle the `var_integer' variable type now, permitting existing parameters defined by GDB proper, such as `listsize', to be accessed from Scheme code. With these changes in place it should be trivial for a Scheme or Python programmer to expand the syntax of the `make-parameter' command and the `gdb.Parameter' class initializer to have arbitrary extra literals along with their internal representation supplied. Update the testsuite accordingly. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-19 21:15:56 +00:00
self->value.intval = (int) val;
break;
}
default:
PyErr_SetString (PyExc_RuntimeError,
_("Unhandled type in parameter value."));
return -1;
}
return 0;
}
gdb/ * python/py-breakpoint.c (bppy_set_condition): New comment. * python/py-cmd.c (cmdpy_function): Call also gdbpy_print_stack for failed PyUnicode_Decode. (cmdpy_completer): Skip element for failed python_string_to_host_string. (cmdpy_init): Return -1 on failed python_string_to_host_string. * python/py-frame.c (frapy_read_var): Extend the function comment. * python/py-function.c (fnpy_init): Return -1 on failed python_string_to_host_string. * python/py-inferior.c (infpy_read_memory, infpy_write_memory): Extend the function comment. (infpy_search_memory): Extend the function comment. Remove the PyErr_SetString call on already set error state. * python/py-param.c (set_parameter_value): Extend the function comment. Return -1 on failed python_string_to_host_string, twice. (set_attr): Extend the function comment. (compute_enum_values): Extend the function comment. New variable back_to. Protect self->enumeration by BACK_TO cleanups. Return 0 on failed python_string_to_host_string. (get_doc_string): Call gdbpy_print_stack on failed python_string_to_host_string. (parmpy_init): Extend the function comment. * python/py-prettyprint.c (pretty_print_one_value): Likewise. (gdbpy_get_display_hint, print_children): Call gdbpy_print_stack on failed python_string_to_host_string. * python/py-value.c (valpy_new, valpy_getitem, valpy_call) (valpy_binop, valpy_richcompare): Extend the function comment. * python/python.c (struct python_env) <error_type, error_value, error_traceback>: New fields. (restore_python_env): Handle PyErr_Occurred. Call PyErr_Restore. (ensure_python_env): Call PyErr_Fetch. * varobj.c (update_dynamic_varobj_children): Call gdbpy_print_stack on failed convert_value_from_python. (value_get_print_value): Call gdbpy_print_stack on failed python_string_to_target_python_string. gdb/testsuite/ * gdb.python/py-error.exp: New file. * gdb.python/py-error.py: New file.
2010-10-13 13:24:40 +00:00
/* Set an attribute. Returns -1 on error, with a python exception set. */
static int
set_attr (PyObject *obj, PyObject *attr_name, PyObject *val)
{
if (PyUnicode_Check (attr_name)
Add support for Python 3. * NEWS: Mention Python 3 support. * varobj.c (value_get_print_value): Use python_string_to_target_string. * python/py-block.c: Use PyVarObject_HEAD_INIT in initialization of type objects. * python/py-breakpoint.c: Ditto. * python/py-cmd.c: Ditto. * python/py-event.c: Ditto. * python/py-event.h: Ditto. * python/py-evtregistry.c: Ditto. * python/py-finishbreakpoint.c: Ditto. * python/py-frame.c: Ditto. * python/py-function.c: Ditto. * python/py-infthread.c: Ditto. * python/py-lazy-string.c: Ditto. * python/py-progspace.c: Ditto. * /python/py-symbol.c: Ditto. * python/py-evts.c: (gdbpy_initialize_py_events): Add module initialization for Python 3. * python/py-inferior.c: Use PyVarObject_HEAD_INIT in initialization of type objects. (infpy_read_memory): Return memoryview object if Python 3. (infpy_write_memory): Use "s*" operand parsing code for Python 3. (infpy_search_memory): Ditto. (get_buffer): New function for Python 3. * python/py-objfile.c: Use PyVarObject_HEAD_INIT in initialization of type objects. (objfpy_dealloc): Use Py_TYPE to call tp_free. * python/py-param.c: Use PyVarObject_HEAD_INIT in initialization of type objects. (get_attr): Use PyUnicode_CompareWithASCIIString if Python 3. (set_attr): Ditto. * python/py-prettyprint.c (print_string_repr): use PyBytes methods instead of PyString methods if Python 3. (print_children): Skip push_dummy_python_frame call if Python 3. * python/py-symtab.c: Use PyVarObject_HEAD_INIT in initialization of type objects. (salpy_dealloc): Use Py_TYPE to call tp_free. * python/py-type.c: Use PyVarObject_HEAD_INIT in initialization of type objects. (field_dealloc): Use Py_TYPE to call tp_free. (typy_dealloc): Ditto. (type_object_as_number): Adjust struct initializations for differences in layout for Python 2 vs. Python 3. * python/py-utils.c (python_string_to_unicode): Omit non-Unicode string case for Python 3. (unicode_to_encoded_python_string): Shorten code (no functional change). (python_string_to_target_python_string): Comment that in Python 3 returned value is a Python "bytes" type. (gdbpy_is_string): Omit non-Unicode string check in Python 3. (gdb_py_object_from_longest): Omit non-long integer case in Python 3. (gdb_py_object_from_ulongest): Ditto. * python/py-value.c: Use PyVarObject_HEAD_INIT in initialization of type objects. (valpy_dealloc): Use Py_TYPE to call tp_free. (valpy_int): Omit function if Python 3. (convert_value_from_python): Use "%S" format (Python object as a string) if Python 3. (value_object_as_number): Adjust struct initializations for differences in layout for Python 2 vs. Python 3. * python/python-config.py: Adjust syntax for Python 3 compatibility. Include "sys.abiflags" string as part of python library name, if that attribute exists (Python 3). * python/python-internal.h (IS_PY3): Define if Python 3. (Py_TPFLAGS_HAVE_ITER, Py_TPFLAGS_CHECKTYPES): Define with placeholder value if Python 3. (PyInt_Check, PyInt_FromLong, PyInt_AsLong, PyString_FromString, PyString_Decode, PyString_FromFormat, PyString_Check): Define as analogous Python 3 API function if Python 3. (PyVarObject_HEAD_INIT): Define if not already defined. (Py_TYPE): Ditto. * python/python.c (eval_python_command): Omit Py_FlushLine call if Python 3. Check return values of all Python API calls for error. Supply dummy "python" and "python-interactive" commands if Python initialization failed. (_initialize_python): Convert argc to wchar_t** if Python 3. Add module initialization for Python 3. (finish_python_initialization): Pass wchar_t * argument to PySys_SetPath if Python 3. * python/lib/gdb/__init__.py: Define "reload" if Python 3. (_GdbFile): New class for common output file behavior. (GdbOutFile): Subclass from _GdbFile. (GdbOutputErrorFile): Ditto. (auto_load_packages): Adjust syntax for Python 3 compatibility. * python/lib/gdb/printing.py: Define basestr and int if Python 3. * python/lib/gdb/prompt.py: Use sorted() function rather than sort() method. * python/lib/gdb/command/explore.py: Define raw_input if Python 3. Adjust syntax for Python 3 compatibility. * python/lib/gdb/command/pretty_printers.py: Use sorted() function rather than sort() method. Adjust syntax for Python 3 compatibility. * python/lib/gdb/command/type_printers.py: Ditto. * doc/gdb.texinfo (Inferior.read_memory): Mention that the return value is a memoryview object if Python 3.
2012-12-12 16:47:30 +00:00
&& ! PyUnicode_CompareWithASCIIString (attr_name, "value"))
{
if (!val)
{
PyErr_SetString (PyExc_RuntimeError,
_("Cannot delete a parameter's value."));
return -1;
}
return set_parameter_value ((parmpy_object *) obj, val);
}
return PyObject_GenericSetAttr (obj, attr_name, val);
}
gdb/python: improve the auto help text for gdb.Parameter This commit attempts to improve the help text that is generated for gdb.Parameter objects when the user fails to provide their own documentation. Documentation for a gdb.Parameter is currently pulled from two sources: the class documentation string, and the set_doc/show_doc class attributes. Thus, a fully documented parameter might look like this: class Param_All (gdb.Parameter): """This is the class documentation string.""" show_doc = "Show the state of this parameter" set_doc = "Set the state of this parameter" def get_set_string (self): val = "on" if (self.value == False): val = "off" return "Test Parameter has been set to " + val def __init__ (self, name): super (Param_All, self).__init__ (name, gdb.COMMAND_DATA, gdb.PARAM_BOOLEAN) self._value = True Param_All ('param-all') Then in GDB we see this: (gdb) help set param-all Set the state of this parameter This is the class documentation string. Which is fine. But, if the user skips both of the documentation parts like this: class Param_None (gdb.Parameter): def get_set_string (self): val = "on" if (self.value == False): val = "off" return "Test Parameter has been set to " + val def __init__ (self, name): super (Param_None, self).__init__ (name, gdb.COMMAND_DATA, gdb.PARAM_BOOLEAN) self._value = True Param_None ('param-none') Now in GDB we see this: (gdb) help set param-none This command is not documented. This command is not documented. That's not great, the duplicated text looks a bit weird. If we drop different parts we get different results. Here's what we get if the user drops the set_doc and show_doc attributes: (gdb) help set param-doc This command is not documented. This is the class documentation string. That kind of sucks, we say it's undocumented, then proceed to print the documentation. Finally, if we drop the class documentation but keep the set_doc and show_doc: (gdb) help set param-set-show Set the state of this parameter This command is not documented. That seems OK. So, I think there's room for improvement. With this patch, for the four cases above we now see this: # All values provided by the user, no change in this case: (gdb) help set param-all Set the state of this parameter This is the class documentation string. # Nothing provided by the user, the first string is now different: (gdb) help set param-none Set the current value of 'param-none'. This command is not documented. # Only the class documentation is provided, the first string is # changed as in the previous case: (gdb) help set param-doc Set the current value of 'param-doc'. This is the class documentation string. # Only the set_doc and show_doc are provided, this case is unchanged # from before the patch: (gdb) help set param-set-show Set the state of this parameter This command is not documented. The one place where this change might be considered a negative is when dealing with prefix commands. If we create a prefix command but don't supply the set_doc / show_doc strings, then this is what we saw before my patch: (gdb) python Param_None ('print param-none') (gdb) help set print set print, set pr, set p Generic command for setting how things print. List of set print subcommands: ... snip ... set print param-none -- This command is not documented. ... snip ... And after my patch: (gdb) python Param_None ('print param-none') (gdb) help set print set print, set pr, set p Generic command for setting how things print. List of set print subcommands: ... snip ... set print param-none -- Set the current value of 'print param-none'. ... snip ... This seems slightly less helpful than before, but I don't think its terrible. Additionally, I've changed what we print when the get_show_string method is not provided in Python. Back when gdb.Parameter was first added to GDB, we didn't provide a show function when registering the internal command object within GDB. As a result, GDB would make use of its "magic" mangling of the show_doc string to create a sentence that would display the current value (see deprecated_show_value_hack in cli/cli-setshow.c). However, when we added support for the get_show_string method to gdb.Parameter, there was an attempt to maintain backward compatibility by displaying the show_doc string with the current value appended, see get_show_value in py-param.c. Unfortunately, this isn't anywhere close to what deprecated_show_value_hack does, and the results are pretty poor, for example, this is GDB before my patch: (gdb) show param-none This command is not documented. off I think we can all agree that this is pretty bad. After my patch, we how show this: (gdb) show param-none The current value of 'param-none' is "off". Which at least is a real sentence, even if it's not very informative. This patch does change the way that the Python API behaves slightly, but only in the cases when the user has missed providing GDB with some information. In most cases I think the new behaviour is a lot better, there's the one case (noted above) which is a bit iffy, but I think is still OK. I've updated the existing gdb.python/py-parameter.exp test to cover the modified behaviour. Finally, I've updated the documentation to (I hope) make it clearer how the various bits of help text come together.
2022-01-07 16:48:49 +00:00
/* Build up the path to command C, but drop the first component of the
command prefix. This is only intended for use with the set/show
parameters this file deals with, the first prefix should always be
either 'set' or 'show'.
As an example, if this full command is 'set prefix_a prefix_b command'
this function will return the string 'prefix_a prefix_b command'. */
static std::string
full_cmd_name_without_first_prefix (struct cmd_list_element *c)
{
std::vector<std::string> components
= c->command_components ();
gdb_assert (components.size () > 1);
std::string result = components[1];
for (int i = 2; i < components.size (); ++i)
result += " " + components[i];
return result;
}
/* The different types of documentation string. */
enum doc_string_type
{
doc_string_set,
doc_string_show,
doc_string_description
};
/* A helper function which returns a documentation string for an
object. */
Use unique_xmalloc_ptr in Python code This changes some utility functions in the Python code to return unique_xmalloc_ptr, and then fixes up the callers. I chose unique_xmalloc_ptr rather than std::string because at a few call points the xmalloc'd string is released and ownership transferred elsewhere. This patch found a few existing memory leaks. For example, py-unwind.c called gdbpy_obj_to_string but never freed the result. Built and regression tested on the buildbot. 2016-11-09 Tom Tromey <tom@tromey.com> * varobj.h (varobj_get_display_hint): Change return type. * varobj.c (varobj_get_display_hint): Return unique_xmalloc_ptr. (varobj_value_get_print_value): Update. * python/python.c (gdbpy_before_prompt_hook, gdbpy_print_stack) (gdbpy_apply_type_printers): Update. * python/python-internal.h (unicode_to_target_string) (python_string_to_target_string, python_string_to_host_string) (gdbpy_obj_to_string, gdbpy_exception_to_string) (gdbpy_get_display_hint): Change return types. * python/py-varobj.c (py_varobj_iter_next): Update. * python/py-value.c (valpy_getitem, convert_value_from_python): Update. * python/py-utils.c (unicode_to_encoded_string) (unicode_to_target_string, python_string_to_target_string) (python_string_to_host_string, gdbpy_obj_to_string) (gdbpy_exception_to_string): Return unique_xmalloc_ptr. * python/py-unwind.c (pyuw_parse_register_id): Update. * python/py-type.c (typy_getitem): Update. * python/py-prettyprint.c (gdbpy_get_display_hint) (print_stack_unless_memory_error, print_children) (gdbpy_apply_val_pretty_printer): Update. * python/py-param.c (set_parameter_value): Update. (get_doc_string, call_doc_function): Return unique_xmalloc_ptr. (get_set_value, get_show_value, compute_enum_values, parmpy_init): Update. * python/py-infthread.c (thpy_set_name): Update. * python/py-function.c (fnpy_call, fnpy_init): Update. * python/py-framefilter.c (extract_sym): Change "name" to unique_xmalloc_ptr. (enumerate_args, enumerate_locals): Update. (py_print_frame): Use unique_xmalloc_ptr. * python/py-frame.c (frapy_read_var): Update. Remove cleanup. * python/py-cmd.c (cmdpy_function, cmdpy_completer, cmdpy_init): Update. * python/py-breakpoint.c (bppy_set_condition): Use unique_xmalloc_ptr. (bppy_init): Likewise. Remove cleanup. (local_setattro): Update. * mi/mi-cmd-var.c (print_varobj, mi_cmd_var_list_children) (varobj_update_one): Update.
2016-10-15 09:20:02 -06:00
static gdb::unique_xmalloc_ptr<char>
gdb/python: improve the auto help text for gdb.Parameter This commit attempts to improve the help text that is generated for gdb.Parameter objects when the user fails to provide their own documentation. Documentation for a gdb.Parameter is currently pulled from two sources: the class documentation string, and the set_doc/show_doc class attributes. Thus, a fully documented parameter might look like this: class Param_All (gdb.Parameter): """This is the class documentation string.""" show_doc = "Show the state of this parameter" set_doc = "Set the state of this parameter" def get_set_string (self): val = "on" if (self.value == False): val = "off" return "Test Parameter has been set to " + val def __init__ (self, name): super (Param_All, self).__init__ (name, gdb.COMMAND_DATA, gdb.PARAM_BOOLEAN) self._value = True Param_All ('param-all') Then in GDB we see this: (gdb) help set param-all Set the state of this parameter This is the class documentation string. Which is fine. But, if the user skips both of the documentation parts like this: class Param_None (gdb.Parameter): def get_set_string (self): val = "on" if (self.value == False): val = "off" return "Test Parameter has been set to " + val def __init__ (self, name): super (Param_None, self).__init__ (name, gdb.COMMAND_DATA, gdb.PARAM_BOOLEAN) self._value = True Param_None ('param-none') Now in GDB we see this: (gdb) help set param-none This command is not documented. This command is not documented. That's not great, the duplicated text looks a bit weird. If we drop different parts we get different results. Here's what we get if the user drops the set_doc and show_doc attributes: (gdb) help set param-doc This command is not documented. This is the class documentation string. That kind of sucks, we say it's undocumented, then proceed to print the documentation. Finally, if we drop the class documentation but keep the set_doc and show_doc: (gdb) help set param-set-show Set the state of this parameter This command is not documented. That seems OK. So, I think there's room for improvement. With this patch, for the four cases above we now see this: # All values provided by the user, no change in this case: (gdb) help set param-all Set the state of this parameter This is the class documentation string. # Nothing provided by the user, the first string is now different: (gdb) help set param-none Set the current value of 'param-none'. This command is not documented. # Only the class documentation is provided, the first string is # changed as in the previous case: (gdb) help set param-doc Set the current value of 'param-doc'. This is the class documentation string. # Only the set_doc and show_doc are provided, this case is unchanged # from before the patch: (gdb) help set param-set-show Set the state of this parameter This command is not documented. The one place where this change might be considered a negative is when dealing with prefix commands. If we create a prefix command but don't supply the set_doc / show_doc strings, then this is what we saw before my patch: (gdb) python Param_None ('print param-none') (gdb) help set print set print, set pr, set p Generic command for setting how things print. List of set print subcommands: ... snip ... set print param-none -- This command is not documented. ... snip ... And after my patch: (gdb) python Param_None ('print param-none') (gdb) help set print set print, set pr, set p Generic command for setting how things print. List of set print subcommands: ... snip ... set print param-none -- Set the current value of 'print param-none'. ... snip ... This seems slightly less helpful than before, but I don't think its terrible. Additionally, I've changed what we print when the get_show_string method is not provided in Python. Back when gdb.Parameter was first added to GDB, we didn't provide a show function when registering the internal command object within GDB. As a result, GDB would make use of its "magic" mangling of the show_doc string to create a sentence that would display the current value (see deprecated_show_value_hack in cli/cli-setshow.c). However, when we added support for the get_show_string method to gdb.Parameter, there was an attempt to maintain backward compatibility by displaying the show_doc string with the current value appended, see get_show_value in py-param.c. Unfortunately, this isn't anywhere close to what deprecated_show_value_hack does, and the results are pretty poor, for example, this is GDB before my patch: (gdb) show param-none This command is not documented. off I think we can all agree that this is pretty bad. After my patch, we how show this: (gdb) show param-none The current value of 'param-none' is "off". Which at least is a real sentence, even if it's not very informative. This patch does change the way that the Python API behaves slightly, but only in the cases when the user has missed providing GDB with some information. In most cases I think the new behaviour is a lot better, there's the one case (noted above) which is a bit iffy, but I think is still OK. I've updated the existing gdb.python/py-parameter.exp test to cover the modified behaviour. Finally, I've updated the documentation to (I hope) make it clearer how the various bits of help text come together.
2022-01-07 16:48:49 +00:00
get_doc_string (PyObject *object, enum doc_string_type doc_type,
const char *cmd_name)
{
Use unique_xmalloc_ptr in Python code This changes some utility functions in the Python code to return unique_xmalloc_ptr, and then fixes up the callers. I chose unique_xmalloc_ptr rather than std::string because at a few call points the xmalloc'd string is released and ownership transferred elsewhere. This patch found a few existing memory leaks. For example, py-unwind.c called gdbpy_obj_to_string but never freed the result. Built and regression tested on the buildbot. 2016-11-09 Tom Tromey <tom@tromey.com> * varobj.h (varobj_get_display_hint): Change return type. * varobj.c (varobj_get_display_hint): Return unique_xmalloc_ptr. (varobj_value_get_print_value): Update. * python/python.c (gdbpy_before_prompt_hook, gdbpy_print_stack) (gdbpy_apply_type_printers): Update. * python/python-internal.h (unicode_to_target_string) (python_string_to_target_string, python_string_to_host_string) (gdbpy_obj_to_string, gdbpy_exception_to_string) (gdbpy_get_display_hint): Change return types. * python/py-varobj.c (py_varobj_iter_next): Update. * python/py-value.c (valpy_getitem, convert_value_from_python): Update. * python/py-utils.c (unicode_to_encoded_string) (unicode_to_target_string, python_string_to_target_string) (python_string_to_host_string, gdbpy_obj_to_string) (gdbpy_exception_to_string): Return unique_xmalloc_ptr. * python/py-unwind.c (pyuw_parse_register_id): Update. * python/py-type.c (typy_getitem): Update. * python/py-prettyprint.c (gdbpy_get_display_hint) (print_stack_unless_memory_error, print_children) (gdbpy_apply_val_pretty_printer): Update. * python/py-param.c (set_parameter_value): Update. (get_doc_string, call_doc_function): Return unique_xmalloc_ptr. (get_set_value, get_show_value, compute_enum_values, parmpy_init): Update. * python/py-infthread.c (thpy_set_name): Update. * python/py-function.c (fnpy_call, fnpy_init): Update. * python/py-framefilter.c (extract_sym): Change "name" to unique_xmalloc_ptr. (enumerate_args, enumerate_locals): Update. (py_print_frame): Use unique_xmalloc_ptr. * python/py-frame.c (frapy_read_var): Update. Remove cleanup. * python/py-cmd.c (cmdpy_function, cmdpy_completer, cmdpy_init): Update. * python/py-breakpoint.c (bppy_set_condition): Use unique_xmalloc_ptr. (bppy_init): Likewise. Remove cleanup. (local_setattro): Update. * mi/mi-cmd-var.c (print_varobj, mi_cmd_var_list_children) (varobj_update_one): Update.
2016-10-15 09:20:02 -06:00
gdb::unique_xmalloc_ptr<char> result;
gdb/python: improve the auto help text for gdb.Parameter This commit attempts to improve the help text that is generated for gdb.Parameter objects when the user fails to provide their own documentation. Documentation for a gdb.Parameter is currently pulled from two sources: the class documentation string, and the set_doc/show_doc class attributes. Thus, a fully documented parameter might look like this: class Param_All (gdb.Parameter): """This is the class documentation string.""" show_doc = "Show the state of this parameter" set_doc = "Set the state of this parameter" def get_set_string (self): val = "on" if (self.value == False): val = "off" return "Test Parameter has been set to " + val def __init__ (self, name): super (Param_All, self).__init__ (name, gdb.COMMAND_DATA, gdb.PARAM_BOOLEAN) self._value = True Param_All ('param-all') Then in GDB we see this: (gdb) help set param-all Set the state of this parameter This is the class documentation string. Which is fine. But, if the user skips both of the documentation parts like this: class Param_None (gdb.Parameter): def get_set_string (self): val = "on" if (self.value == False): val = "off" return "Test Parameter has been set to " + val def __init__ (self, name): super (Param_None, self).__init__ (name, gdb.COMMAND_DATA, gdb.PARAM_BOOLEAN) self._value = True Param_None ('param-none') Now in GDB we see this: (gdb) help set param-none This command is not documented. This command is not documented. That's not great, the duplicated text looks a bit weird. If we drop different parts we get different results. Here's what we get if the user drops the set_doc and show_doc attributes: (gdb) help set param-doc This command is not documented. This is the class documentation string. That kind of sucks, we say it's undocumented, then proceed to print the documentation. Finally, if we drop the class documentation but keep the set_doc and show_doc: (gdb) help set param-set-show Set the state of this parameter This command is not documented. That seems OK. So, I think there's room for improvement. With this patch, for the four cases above we now see this: # All values provided by the user, no change in this case: (gdb) help set param-all Set the state of this parameter This is the class documentation string. # Nothing provided by the user, the first string is now different: (gdb) help set param-none Set the current value of 'param-none'. This command is not documented. # Only the class documentation is provided, the first string is # changed as in the previous case: (gdb) help set param-doc Set the current value of 'param-doc'. This is the class documentation string. # Only the set_doc and show_doc are provided, this case is unchanged # from before the patch: (gdb) help set param-set-show Set the state of this parameter This command is not documented. The one place where this change might be considered a negative is when dealing with prefix commands. If we create a prefix command but don't supply the set_doc / show_doc strings, then this is what we saw before my patch: (gdb) python Param_None ('print param-none') (gdb) help set print set print, set pr, set p Generic command for setting how things print. List of set print subcommands: ... snip ... set print param-none -- This command is not documented. ... snip ... And after my patch: (gdb) python Param_None ('print param-none') (gdb) help set print set print, set pr, set p Generic command for setting how things print. List of set print subcommands: ... snip ... set print param-none -- Set the current value of 'print param-none'. ... snip ... This seems slightly less helpful than before, but I don't think its terrible. Additionally, I've changed what we print when the get_show_string method is not provided in Python. Back when gdb.Parameter was first added to GDB, we didn't provide a show function when registering the internal command object within GDB. As a result, GDB would make use of its "magic" mangling of the show_doc string to create a sentence that would display the current value (see deprecated_show_value_hack in cli/cli-setshow.c). However, when we added support for the get_show_string method to gdb.Parameter, there was an attempt to maintain backward compatibility by displaying the show_doc string with the current value appended, see get_show_value in py-param.c. Unfortunately, this isn't anywhere close to what deprecated_show_value_hack does, and the results are pretty poor, for example, this is GDB before my patch: (gdb) show param-none This command is not documented. off I think we can all agree that this is pretty bad. After my patch, we how show this: (gdb) show param-none The current value of 'param-none' is "off". Which at least is a real sentence, even if it's not very informative. This patch does change the way that the Python API behaves slightly, but only in the cases when the user has missed providing GDB with some information. In most cases I think the new behaviour is a lot better, there's the one case (noted above) which is a bit iffy, but I think is still OK. I've updated the existing gdb.python/py-parameter.exp test to cover the modified behaviour. Finally, I've updated the documentation to (I hope) make it clearer how the various bits of help text come together.
2022-01-07 16:48:49 +00:00
PyObject *attr = nullptr;
switch (doc_type)
{
case doc_string_set:
attr = set_doc_cst;
break;
case doc_string_show:
attr = show_doc_cst;
break;
case doc_string_description:
attr = gdbpy_doc_cst;
break;
}
gdb_assert (attr != nullptr);
if (PyObject_HasAttr (object, attr))
{
gdbpy_ref<> ds_obj (PyObject_GetAttr (object, attr));
if (ds_obj != NULL && gdbpy_is_string (ds_obj.get ()))
{
result = python_string_to_host_string (ds_obj.get ());
if (result == NULL)
gdbpy_print_stack ();
gdb/python: improve formatting of help text for user defined commands Consider this command defined in Python (in the file test-cmd.py): class test_cmd (gdb.Command): """ This is the first line. Indented second line. This is the third line. """ def __init__ (self): super ().__init__ ("test-cmd", gdb.COMMAND_OBSCURE) def invoke (self, arg, from_tty): print ("In test-cmd") test_cmd() Now, within a GDB session: (gdb) source test-cmd.py (gdb) help test-cmd This is the first line. Indented second line. This is the third line. (gdb) I think there's three things wrong here: 1. The leading blank line, 2. The trailing blank line, and 3. Every line is indented from the left edge slightly. The problem of course, is that GDB is using the Python doc string verbatim as its help text. While the user has formatted the help text so that it appears clear within the .py file, this means that the text appear less well formatted when displayed in the "help" output. The same problem can be observed for gdb.Parameter objects in their set/show output. In this commit I aim to improve the "help" output for commands and parameters. To do this I have added gdbpy_fix_doc_string_indentation, a new function that rewrites the doc string text following the following rules: 1. Leading blank lines are removed, 2. Trailing blank lines are removed, and 3. Leading whitespace is removed in a "smart" way such that the relative indentation of lines is retained. With this commit in place the above example now looks like this: (gdb) source ~/tmp/test-cmd.py (gdb) help test-cmd This is the first line. Indented second line. This is the third line. (gdb) Which I think is much neater. Notice that the indentation of the second line is retained. Any blank lines within the help text (not leading or trailing) will be retained. I've added a NEWS entry to note that there has been a change in behaviour, but I didn't update the manual. The existing manual is suitably vague about how the doc string is used, so I think the new behaviour is covered just as well by the existing text.
2022-05-16 19:26:54 +01:00
else if (doc_type == doc_string_description)
result = gdbpy_fix_doc_string_indentation (std::move (result));
}
}
gdb/python: improve the auto help text for gdb.Parameter This commit attempts to improve the help text that is generated for gdb.Parameter objects when the user fails to provide their own documentation. Documentation for a gdb.Parameter is currently pulled from two sources: the class documentation string, and the set_doc/show_doc class attributes. Thus, a fully documented parameter might look like this: class Param_All (gdb.Parameter): """This is the class documentation string.""" show_doc = "Show the state of this parameter" set_doc = "Set the state of this parameter" def get_set_string (self): val = "on" if (self.value == False): val = "off" return "Test Parameter has been set to " + val def __init__ (self, name): super (Param_All, self).__init__ (name, gdb.COMMAND_DATA, gdb.PARAM_BOOLEAN) self._value = True Param_All ('param-all') Then in GDB we see this: (gdb) help set param-all Set the state of this parameter This is the class documentation string. Which is fine. But, if the user skips both of the documentation parts like this: class Param_None (gdb.Parameter): def get_set_string (self): val = "on" if (self.value == False): val = "off" return "Test Parameter has been set to " + val def __init__ (self, name): super (Param_None, self).__init__ (name, gdb.COMMAND_DATA, gdb.PARAM_BOOLEAN) self._value = True Param_None ('param-none') Now in GDB we see this: (gdb) help set param-none This command is not documented. This command is not documented. That's not great, the duplicated text looks a bit weird. If we drop different parts we get different results. Here's what we get if the user drops the set_doc and show_doc attributes: (gdb) help set param-doc This command is not documented. This is the class documentation string. That kind of sucks, we say it's undocumented, then proceed to print the documentation. Finally, if we drop the class documentation but keep the set_doc and show_doc: (gdb) help set param-set-show Set the state of this parameter This command is not documented. That seems OK. So, I think there's room for improvement. With this patch, for the four cases above we now see this: # All values provided by the user, no change in this case: (gdb) help set param-all Set the state of this parameter This is the class documentation string. # Nothing provided by the user, the first string is now different: (gdb) help set param-none Set the current value of 'param-none'. This command is not documented. # Only the class documentation is provided, the first string is # changed as in the previous case: (gdb) help set param-doc Set the current value of 'param-doc'. This is the class documentation string. # Only the set_doc and show_doc are provided, this case is unchanged # from before the patch: (gdb) help set param-set-show Set the state of this parameter This command is not documented. The one place where this change might be considered a negative is when dealing with prefix commands. If we create a prefix command but don't supply the set_doc / show_doc strings, then this is what we saw before my patch: (gdb) python Param_None ('print param-none') (gdb) help set print set print, set pr, set p Generic command for setting how things print. List of set print subcommands: ... snip ... set print param-none -- This command is not documented. ... snip ... And after my patch: (gdb) python Param_None ('print param-none') (gdb) help set print set print, set pr, set p Generic command for setting how things print. List of set print subcommands: ... snip ... set print param-none -- Set the current value of 'print param-none'. ... snip ... This seems slightly less helpful than before, but I don't think its terrible. Additionally, I've changed what we print when the get_show_string method is not provided in Python. Back when gdb.Parameter was first added to GDB, we didn't provide a show function when registering the internal command object within GDB. As a result, GDB would make use of its "magic" mangling of the show_doc string to create a sentence that would display the current value (see deprecated_show_value_hack in cli/cli-setshow.c). However, when we added support for the get_show_string method to gdb.Parameter, there was an attempt to maintain backward compatibility by displaying the show_doc string with the current value appended, see get_show_value in py-param.c. Unfortunately, this isn't anywhere close to what deprecated_show_value_hack does, and the results are pretty poor, for example, this is GDB before my patch: (gdb) show param-none This command is not documented. off I think we can all agree that this is pretty bad. After my patch, we how show this: (gdb) show param-none The current value of 'param-none' is "off". Which at least is a real sentence, even if it's not very informative. This patch does change the way that the Python API behaves slightly, but only in the cases when the user has missed providing GDB with some information. In most cases I think the new behaviour is a lot better, there's the one case (noted above) which is a bit iffy, but I think is still OK. I've updated the existing gdb.python/py-parameter.exp test to cover the modified behaviour. Finally, I've updated the documentation to (I hope) make it clearer how the various bits of help text come together.
2022-01-07 16:48:49 +00:00
gdb/python: allow empty gdb.Parameter.__doc__ string I was recently attempting to create some parameters via the Python API. I wanted these parameters to appear similar to how GDB handles the existing 'style' parameters. Specifically, I was interested in this behaviour: (gdb) help show style filename foreground Show the foreground color for this property. (gdb) help set style filename foreground Set the foreground color for this property. (gdb) Notice how each 'help' command only gets a single line of output. I tried to reproduce this behaviour via the Python API and was unable. The problem is that, in order to get just a single line of output like this, the style parameters are registered with a call to add_setshow_color_cmd with the 'help_doc' being passed as nullptr. On the Python side, when parameters are created, the 'help_doc' is obtained with a call to get_doc_string (python/py-param.c). This function either returns the __doc__ string, or a default string: "This command is not documented.". To avoid returning the default we could try setting __doc__ to an empty string, but setting this field to any string means that GDB prints a line for that string, like this: class test_param(gdb.Parameter): __doc__ = "" def __init__(self, name): super ().__init__(name, gdb.COMMAND_NONE, gdb.PARAM_BOOLEAN) self.value = True test_param('print test') Then in GDB: (gdb) help set print test Set the current value of 'print test'. (gdb) The blank line is the problem I'd like to solve. This commit makes a couple of changes to how parameter doc strings are handled. If the doc string is set to an empty string, then GDB now converts this to nullptr, which removes the blank line problem, the new behaviour in GDB (for the above `test_param`) is: (gdb) help set print test Set the current value of 'print test'. (gdb) Next, I noticed that if the set/show docs are set to empty strings, then the results are less than ideal: class test_param(gdb.Parameter): set_doc = "" def __init__(self, name): super ().__init__(name, gdb.COMMAND_NONE, gdb.PARAM_BOOLEAN) self.value = True test_param('print test') And in GDB: (gdb) help set print test This command is not documented. (gdb) So, if the set/show docs are the empty string, GDB now forces these to be the default string instead, the new behaviour in GDB is: (gdb) help set print test Set the current value of 'print test'. This command is not documented. (gdb) I've added some additional asserts; the set/show docs should always be non-empty strings, which I believe is the case after this commit. And the 'doc' string returned from get_doc_string should never nullptr, but could be empty. There are new tests to cover all these changes.
2025-04-11 23:45:51 +01:00
/* For the set/show docs, if these strings are empty then we set then to
a non-empty string. This ensures that the command has some sane
documentation for its 'help' text. */
if (result == nullptr
|| (doc_type != doc_string_description && *result == '\0'))
gdb/python: improve the auto help text for gdb.Parameter This commit attempts to improve the help text that is generated for gdb.Parameter objects when the user fails to provide their own documentation. Documentation for a gdb.Parameter is currently pulled from two sources: the class documentation string, and the set_doc/show_doc class attributes. Thus, a fully documented parameter might look like this: class Param_All (gdb.Parameter): """This is the class documentation string.""" show_doc = "Show the state of this parameter" set_doc = "Set the state of this parameter" def get_set_string (self): val = "on" if (self.value == False): val = "off" return "Test Parameter has been set to " + val def __init__ (self, name): super (Param_All, self).__init__ (name, gdb.COMMAND_DATA, gdb.PARAM_BOOLEAN) self._value = True Param_All ('param-all') Then in GDB we see this: (gdb) help set param-all Set the state of this parameter This is the class documentation string. Which is fine. But, if the user skips both of the documentation parts like this: class Param_None (gdb.Parameter): def get_set_string (self): val = "on" if (self.value == False): val = "off" return "Test Parameter has been set to " + val def __init__ (self, name): super (Param_None, self).__init__ (name, gdb.COMMAND_DATA, gdb.PARAM_BOOLEAN) self._value = True Param_None ('param-none') Now in GDB we see this: (gdb) help set param-none This command is not documented. This command is not documented. That's not great, the duplicated text looks a bit weird. If we drop different parts we get different results. Here's what we get if the user drops the set_doc and show_doc attributes: (gdb) help set param-doc This command is not documented. This is the class documentation string. That kind of sucks, we say it's undocumented, then proceed to print the documentation. Finally, if we drop the class documentation but keep the set_doc and show_doc: (gdb) help set param-set-show Set the state of this parameter This command is not documented. That seems OK. So, I think there's room for improvement. With this patch, for the four cases above we now see this: # All values provided by the user, no change in this case: (gdb) help set param-all Set the state of this parameter This is the class documentation string. # Nothing provided by the user, the first string is now different: (gdb) help set param-none Set the current value of 'param-none'. This command is not documented. # Only the class documentation is provided, the first string is # changed as in the previous case: (gdb) help set param-doc Set the current value of 'param-doc'. This is the class documentation string. # Only the set_doc and show_doc are provided, this case is unchanged # from before the patch: (gdb) help set param-set-show Set the state of this parameter This command is not documented. The one place where this change might be considered a negative is when dealing with prefix commands. If we create a prefix command but don't supply the set_doc / show_doc strings, then this is what we saw before my patch: (gdb) python Param_None ('print param-none') (gdb) help set print set print, set pr, set p Generic command for setting how things print. List of set print subcommands: ... snip ... set print param-none -- This command is not documented. ... snip ... And after my patch: (gdb) python Param_None ('print param-none') (gdb) help set print set print, set pr, set p Generic command for setting how things print. List of set print subcommands: ... snip ... set print param-none -- Set the current value of 'print param-none'. ... snip ... This seems slightly less helpful than before, but I don't think its terrible. Additionally, I've changed what we print when the get_show_string method is not provided in Python. Back when gdb.Parameter was first added to GDB, we didn't provide a show function when registering the internal command object within GDB. As a result, GDB would make use of its "magic" mangling of the show_doc string to create a sentence that would display the current value (see deprecated_show_value_hack in cli/cli-setshow.c). However, when we added support for the get_show_string method to gdb.Parameter, there was an attempt to maintain backward compatibility by displaying the show_doc string with the current value appended, see get_show_value in py-param.c. Unfortunately, this isn't anywhere close to what deprecated_show_value_hack does, and the results are pretty poor, for example, this is GDB before my patch: (gdb) show param-none This command is not documented. off I think we can all agree that this is pretty bad. After my patch, we how show this: (gdb) show param-none The current value of 'param-none' is "off". Which at least is a real sentence, even if it's not very informative. This patch does change the way that the Python API behaves slightly, but only in the cases when the user has missed providing GDB with some information. In most cases I think the new behaviour is a lot better, there's the one case (noted above) which is a bit iffy, but I think is still OK. I've updated the existing gdb.python/py-parameter.exp test to cover the modified behaviour. Finally, I've updated the documentation to (I hope) make it clearer how the various bits of help text come together.
2022-01-07 16:48:49 +00:00
{
if (doc_type == doc_string_description)
result = make_unique_xstrdup (_("This command is not documented."));
gdb/python: improve the auto help text for gdb.Parameter This commit attempts to improve the help text that is generated for gdb.Parameter objects when the user fails to provide their own documentation. Documentation for a gdb.Parameter is currently pulled from two sources: the class documentation string, and the set_doc/show_doc class attributes. Thus, a fully documented parameter might look like this: class Param_All (gdb.Parameter): """This is the class documentation string.""" show_doc = "Show the state of this parameter" set_doc = "Set the state of this parameter" def get_set_string (self): val = "on" if (self.value == False): val = "off" return "Test Parameter has been set to " + val def __init__ (self, name): super (Param_All, self).__init__ (name, gdb.COMMAND_DATA, gdb.PARAM_BOOLEAN) self._value = True Param_All ('param-all') Then in GDB we see this: (gdb) help set param-all Set the state of this parameter This is the class documentation string. Which is fine. But, if the user skips both of the documentation parts like this: class Param_None (gdb.Parameter): def get_set_string (self): val = "on" if (self.value == False): val = "off" return "Test Parameter has been set to " + val def __init__ (self, name): super (Param_None, self).__init__ (name, gdb.COMMAND_DATA, gdb.PARAM_BOOLEAN) self._value = True Param_None ('param-none') Now in GDB we see this: (gdb) help set param-none This command is not documented. This command is not documented. That's not great, the duplicated text looks a bit weird. If we drop different parts we get different results. Here's what we get if the user drops the set_doc and show_doc attributes: (gdb) help set param-doc This command is not documented. This is the class documentation string. That kind of sucks, we say it's undocumented, then proceed to print the documentation. Finally, if we drop the class documentation but keep the set_doc and show_doc: (gdb) help set param-set-show Set the state of this parameter This command is not documented. That seems OK. So, I think there's room for improvement. With this patch, for the four cases above we now see this: # All values provided by the user, no change in this case: (gdb) help set param-all Set the state of this parameter This is the class documentation string. # Nothing provided by the user, the first string is now different: (gdb) help set param-none Set the current value of 'param-none'. This command is not documented. # Only the class documentation is provided, the first string is # changed as in the previous case: (gdb) help set param-doc Set the current value of 'param-doc'. This is the class documentation string. # Only the set_doc and show_doc are provided, this case is unchanged # from before the patch: (gdb) help set param-set-show Set the state of this parameter This command is not documented. The one place where this change might be considered a negative is when dealing with prefix commands. If we create a prefix command but don't supply the set_doc / show_doc strings, then this is what we saw before my patch: (gdb) python Param_None ('print param-none') (gdb) help set print set print, set pr, set p Generic command for setting how things print. List of set print subcommands: ... snip ... set print param-none -- This command is not documented. ... snip ... And after my patch: (gdb) python Param_None ('print param-none') (gdb) help set print set print, set pr, set p Generic command for setting how things print. List of set print subcommands: ... snip ... set print param-none -- Set the current value of 'print param-none'. ... snip ... This seems slightly less helpful than before, but I don't think its terrible. Additionally, I've changed what we print when the get_show_string method is not provided in Python. Back when gdb.Parameter was first added to GDB, we didn't provide a show function when registering the internal command object within GDB. As a result, GDB would make use of its "magic" mangling of the show_doc string to create a sentence that would display the current value (see deprecated_show_value_hack in cli/cli-setshow.c). However, when we added support for the get_show_string method to gdb.Parameter, there was an attempt to maintain backward compatibility by displaying the show_doc string with the current value appended, see get_show_value in py-param.c. Unfortunately, this isn't anywhere close to what deprecated_show_value_hack does, and the results are pretty poor, for example, this is GDB before my patch: (gdb) show param-none This command is not documented. off I think we can all agree that this is pretty bad. After my patch, we how show this: (gdb) show param-none The current value of 'param-none' is "off". Which at least is a real sentence, even if it's not very informative. This patch does change the way that the Python API behaves slightly, but only in the cases when the user has missed providing GDB with some information. In most cases I think the new behaviour is a lot better, there's the one case (noted above) which is a bit iffy, but I think is still OK. I've updated the existing gdb.python/py-parameter.exp test to cover the modified behaviour. Finally, I've updated the documentation to (I hope) make it clearer how the various bits of help text come together.
2022-01-07 16:48:49 +00:00
else
{
if (doc_type == doc_string_show)
result = xstrprintf (_("Show the current value of '%s'."),
cmd_name);
else
result = xstrprintf (_("Set the current value of '%s'."),
cmd_name);
}
}
return result;
}
/* Helper function which will execute a METHOD in OBJ passing the
argument ARG. ARG can be NULL. METHOD should return a Python
string. If this function returns NULL, there has been an error and
the appropriate exception set. */
Use unique_xmalloc_ptr in Python code This changes some utility functions in the Python code to return unique_xmalloc_ptr, and then fixes up the callers. I chose unique_xmalloc_ptr rather than std::string because at a few call points the xmalloc'd string is released and ownership transferred elsewhere. This patch found a few existing memory leaks. For example, py-unwind.c called gdbpy_obj_to_string but never freed the result. Built and regression tested on the buildbot. 2016-11-09 Tom Tromey <tom@tromey.com> * varobj.h (varobj_get_display_hint): Change return type. * varobj.c (varobj_get_display_hint): Return unique_xmalloc_ptr. (varobj_value_get_print_value): Update. * python/python.c (gdbpy_before_prompt_hook, gdbpy_print_stack) (gdbpy_apply_type_printers): Update. * python/python-internal.h (unicode_to_target_string) (python_string_to_target_string, python_string_to_host_string) (gdbpy_obj_to_string, gdbpy_exception_to_string) (gdbpy_get_display_hint): Change return types. * python/py-varobj.c (py_varobj_iter_next): Update. * python/py-value.c (valpy_getitem, convert_value_from_python): Update. * python/py-utils.c (unicode_to_encoded_string) (unicode_to_target_string, python_string_to_target_string) (python_string_to_host_string, gdbpy_obj_to_string) (gdbpy_exception_to_string): Return unique_xmalloc_ptr. * python/py-unwind.c (pyuw_parse_register_id): Update. * python/py-type.c (typy_getitem): Update. * python/py-prettyprint.c (gdbpy_get_display_hint) (print_stack_unless_memory_error, print_children) (gdbpy_apply_val_pretty_printer): Update. * python/py-param.c (set_parameter_value): Update. (get_doc_string, call_doc_function): Return unique_xmalloc_ptr. (get_set_value, get_show_value, compute_enum_values, parmpy_init): Update. * python/py-infthread.c (thpy_set_name): Update. * python/py-function.c (fnpy_call, fnpy_init): Update. * python/py-framefilter.c (extract_sym): Change "name" to unique_xmalloc_ptr. (enumerate_args, enumerate_locals): Update. (py_print_frame): Use unique_xmalloc_ptr. * python/py-frame.c (frapy_read_var): Update. Remove cleanup. * python/py-cmd.c (cmdpy_function, cmdpy_completer, cmdpy_init): Update. * python/py-breakpoint.c (bppy_set_condition): Use unique_xmalloc_ptr. (bppy_init): Likewise. Remove cleanup. (local_setattro): Update. * mi/mi-cmd-var.c (print_varobj, mi_cmd_var_list_children) (varobj_update_one): Update.
2016-10-15 09:20:02 -06:00
static gdb::unique_xmalloc_ptr<char>
call_doc_function (PyObject *obj, PyObject *method, PyObject *arg)
{
Use unique_xmalloc_ptr in Python code This changes some utility functions in the Python code to return unique_xmalloc_ptr, and then fixes up the callers. I chose unique_xmalloc_ptr rather than std::string because at a few call points the xmalloc'd string is released and ownership transferred elsewhere. This patch found a few existing memory leaks. For example, py-unwind.c called gdbpy_obj_to_string but never freed the result. Built and regression tested on the buildbot. 2016-11-09 Tom Tromey <tom@tromey.com> * varobj.h (varobj_get_display_hint): Change return type. * varobj.c (varobj_get_display_hint): Return unique_xmalloc_ptr. (varobj_value_get_print_value): Update. * python/python.c (gdbpy_before_prompt_hook, gdbpy_print_stack) (gdbpy_apply_type_printers): Update. * python/python-internal.h (unicode_to_target_string) (python_string_to_target_string, python_string_to_host_string) (gdbpy_obj_to_string, gdbpy_exception_to_string) (gdbpy_get_display_hint): Change return types. * python/py-varobj.c (py_varobj_iter_next): Update. * python/py-value.c (valpy_getitem, convert_value_from_python): Update. * python/py-utils.c (unicode_to_encoded_string) (unicode_to_target_string, python_string_to_target_string) (python_string_to_host_string, gdbpy_obj_to_string) (gdbpy_exception_to_string): Return unique_xmalloc_ptr. * python/py-unwind.c (pyuw_parse_register_id): Update. * python/py-type.c (typy_getitem): Update. * python/py-prettyprint.c (gdbpy_get_display_hint) (print_stack_unless_memory_error, print_children) (gdbpy_apply_val_pretty_printer): Update. * python/py-param.c (set_parameter_value): Update. (get_doc_string, call_doc_function): Return unique_xmalloc_ptr. (get_set_value, get_show_value, compute_enum_values, parmpy_init): Update. * python/py-infthread.c (thpy_set_name): Update. * python/py-function.c (fnpy_call, fnpy_init): Update. * python/py-framefilter.c (extract_sym): Change "name" to unique_xmalloc_ptr. (enumerate_args, enumerate_locals): Update. (py_print_frame): Use unique_xmalloc_ptr. * python/py-frame.c (frapy_read_var): Update. Remove cleanup. * python/py-cmd.c (cmdpy_function, cmdpy_completer, cmdpy_init): Update. * python/py-breakpoint.c (bppy_set_condition): Use unique_xmalloc_ptr. (bppy_init): Likewise. Remove cleanup. (local_setattro): Update. * mi/mi-cmd-var.c (print_varobj, mi_cmd_var_list_children) (varobj_update_one): Update.
2016-10-15 09:20:02 -06:00
gdb::unique_xmalloc_ptr<char> data;
gdbpy_ref<> result (PyObject_CallMethodObjArgs (obj, method, arg, NULL));
if (result == NULL)
return NULL;
if (gdbpy_is_string (result.get ()))
{
data = python_string_to_host_string (result.get ());
if (! data)
return NULL;
}
else
{
PyErr_SetString (PyExc_RuntimeError,
_("Parameter must return a string value."));
return NULL;
}
return data;
}
/* A callback function that is registered against the respective
add_setshow_* set_doc prototype. This function calls the Python function
"get_set_string" if it exists, which will return a string. That string
is then printed. If "get_set_string" does not exist, or returns an
empty string, then nothing is printed. */
static void
Constify add_setshow_* This constifies the add_setshow_* family of functions, and then fixes up the fallout. The bulk of this patch was written by script. gdb/ChangeLog 2017-11-07 Tom Tromey <tom@tromey.com> * ada-lang.c (catch_ada_exception_command): Constify. (catch_assert_command): Constify. * break-catch-throw.c (catch_catch_command, catch_throw_command) (catch_rethrow_command): Constify. (catch_exception_command_1): Constify. * breakpoint.h (add_catch_command): Constify. * break-catch-syscall.c (catch_syscall_command_1): Constify. (catch_syscall_split_args): Constify. * break-catch-sig.c (catch_signal_command): Constify. (catch_signal_split_args): Constify. * cli/cli-decode.h (struct cmd_list_element) <function>: Use cmd_const_sfunc_ftype. * cli/cli-decode.c (add_setshow_cmd_full): Constify. (add_setshow_enum_cmd, add_setshow_auto_boolean_cmd) (add_setshow_boolean_cmd, add_setshow_filename_cmd) (add_setshow_string_cmd, struct cmd_list_element) (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): Constify. (set_cmd_sfunc): Constify. (empty_sfunc): Constify. * command.h (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): Constify. (set_cmd_sfunc): Constify. (cmd_sfunc_ftype): Remove. * compile/compile.c (set_compile_args): Constify. * infrun.c (set_disable_randomization): Constify. * infcmd.c (set_args_command, set_cwd_command): Constify. * breakpoint.c (set_condition_evaluation_mode): Constify. (add_catch_command): Constify. (catch_fork_command_1, catch_exec_command_1) (catch_load_command_1, catch_unload_command_1): Constify. (catch_load_or_unload): Constify. * guile/scm-param.c (pascm_set_func): Constify. (add_setshow_generic): Constify. * python/py-param.c (get_set_value): Constify. * top.h (set_verbose): Constify. * tui/tui-win.c (tui_set_var_cmd): Constify. * mi/mi-main.c (set_mi_async_command): Constify. * cli/cli-logging.c (set_logging_overwrite) (set_logging_redirect): Constify. * value.c (set_max_value_size): Constify. * valprint.c (set_input_radix, set_output_radix): Constify. * utils.c (set_width_command, set_height_command): Constify. * typeprint.c (set_print_type_methods, set_print_type_typedefs): Constify. * tracepoint.c (set_disconnected_tracing) (set_circular_trace_buffer, set_trace_buffer_size) (set_trace_user, set_trace_notes, set_trace_stop_notes): Constify. * top.c (set_history_size_command, set_verbose, set_editing) (set_gdb_datadir, set_history_filename): Constify. * target.c (set_targetdebug, maint_set_target_async_command) (maint_set_target_non_stop_command, set_target_permissions) (set_write_memory_permission): Constify. (open_target): Constify. * target-descriptions.c (set_tdesc_filename_cmd): Constify. * target-dcache.c (set_stack_cache, set_code_cache): Constify. * symtab.c (set_symbol_cache_size_handler): Constify. * symfile.c (set_ext_lang_command): Constify. * symfile-debug.c (set_debug_symfile): Constify. * source.c (set_directories_command): Constify. * solib.c (reload_shared_libraries, gdb_sysroot_changed): Constify. * serial.c (set_parity): Constify. * rs6000-tdep.c (powerpc_set_soft_float, powerpc_set_vector_abi): Constify. * remote.c (set_remote_exec_file, set_remotebreak) (set_remote_protocol_Z_packet_cmd, set_range_stepping): Constify. * record.c (set_record_insn_history_size) (set_record_call_history_size): Constify. * record-full.c (set_record_full_insn_max_num): Constify. * proc-api.c (set_procfs_trace_cmd, set_procfs_file_cmd): Constify. * osabi.c (set_osabi): Constify. * mips-tdep.c (set_mips64_transfers_32bit_regs) (reinit_frame_cache_sfunc, mips_abi_update): Constify. * maint.c (maintenance_set_profile_cmd): Constify. * linux-thread-db.c (set_libthread_db_search_path): Constify. * language.c (set_language_command, set_range_command) (set_case_command): Constify. * infrun.c (set_non_stop, set_observer_mode) (set_stop_on_solib_events, set_schedlock_func) (set_exec_direction_func): Constify. * infcmd.c (set_inferior_tty_command): Constify. * disasm.c (set_disassembler_options_sfunc): Constify. * demangle.c (set_demangling_command): Constify. * dcache.c (set_dcache_size, set_dcache_line_size): Constify. * cris-tdep.c (set_cris_version, set_cris_mode) (set_cris_dwarf2_cfi): Constify. * corefile.c (set_gnutarget_command): Constify. * charset.c (set_host_charset_sfunc, set_target_charset_sfunc) (set_target_wide_charset_sfunc): Constify. * breakpoint.c (update_dprintf_commands): Constify. * auto-load.c (set_auto_load_dir, set_auto_load_safe_path): Constify. * arm-tdep.c (set_fp_model_sfunc, arm_set_abi) (set_disassembly_style_sfunc): Constify. * arch-utils.c (set_endian, set_architecture): Constify. * alpha-tdep.c (reinit_frame_cache_sfunc): Constify. * agent.c (set_can_use_agent): Constify.
2017-10-14 09:07:00 -06:00
get_set_value (const char *args, int from_tty,
struct cmd_list_element *c)
{
PyObject *obj = (PyObject *) c->context ();
Use unique_xmalloc_ptr in Python code This changes some utility functions in the Python code to return unique_xmalloc_ptr, and then fixes up the callers. I chose unique_xmalloc_ptr rather than std::string because at a few call points the xmalloc'd string is released and ownership transferred elsewhere. This patch found a few existing memory leaks. For example, py-unwind.c called gdbpy_obj_to_string but never freed the result. Built and regression tested on the buildbot. 2016-11-09 Tom Tromey <tom@tromey.com> * varobj.h (varobj_get_display_hint): Change return type. * varobj.c (varobj_get_display_hint): Return unique_xmalloc_ptr. (varobj_value_get_print_value): Update. * python/python.c (gdbpy_before_prompt_hook, gdbpy_print_stack) (gdbpy_apply_type_printers): Update. * python/python-internal.h (unicode_to_target_string) (python_string_to_target_string, python_string_to_host_string) (gdbpy_obj_to_string, gdbpy_exception_to_string) (gdbpy_get_display_hint): Change return types. * python/py-varobj.c (py_varobj_iter_next): Update. * python/py-value.c (valpy_getitem, convert_value_from_python): Update. * python/py-utils.c (unicode_to_encoded_string) (unicode_to_target_string, python_string_to_target_string) (python_string_to_host_string, gdbpy_obj_to_string) (gdbpy_exception_to_string): Return unique_xmalloc_ptr. * python/py-unwind.c (pyuw_parse_register_id): Update. * python/py-type.c (typy_getitem): Update. * python/py-prettyprint.c (gdbpy_get_display_hint) (print_stack_unless_memory_error, print_children) (gdbpy_apply_val_pretty_printer): Update. * python/py-param.c (set_parameter_value): Update. (get_doc_string, call_doc_function): Return unique_xmalloc_ptr. (get_set_value, get_show_value, compute_enum_values, parmpy_init): Update. * python/py-infthread.c (thpy_set_name): Update. * python/py-function.c (fnpy_call, fnpy_init): Update. * python/py-framefilter.c (extract_sym): Change "name" to unique_xmalloc_ptr. (enumerate_args, enumerate_locals): Update. (py_print_frame): Use unique_xmalloc_ptr. * python/py-frame.c (frapy_read_var): Update. Remove cleanup. * python/py-cmd.c (cmdpy_function, cmdpy_completer, cmdpy_init): Update. * python/py-breakpoint.c (bppy_set_condition): Use unique_xmalloc_ptr. (bppy_init): Likewise. Remove cleanup. (local_setattro): Update. * mi/mi-cmd-var.c (print_varobj, mi_cmd_var_list_children) (varobj_update_one): Update.
2016-10-15 09:20:02 -06:00
gdb::unique_xmalloc_ptr<char> set_doc_string;
gdbpy_enter enter_py;
gdbpy_ref<> set_doc_func (PyUnicode_FromString ("get_set_string"));
if (set_doc_func == NULL)
{
gdbpy_print_stack ();
return;
}
if (PyObject_HasAttr (obj, set_doc_func.get ()))
{
set_doc_string = call_doc_function (obj, set_doc_func.get (), NULL);
if (! set_doc_string)
gdbpy_handle_exception ();
}
const char *str = set_doc_string.get ();
if (str != nullptr && str[0] != '\0')
gdb_printf ("%s\n", str);
}
/* A callback function that is registered against the respective
add_setshow_* show_doc prototype. This function will either call
the Python function "get_show_string" or extract the Python
attribute "show_doc" and return the contents as a string. If
neither exist, insert a string indicating the Parameter is not
documented. */
static void
get_show_value (struct ui_file *file, int from_tty,
struct cmd_list_element *c,
const char *value)
{
PyObject *obj = (PyObject *) c->context ();
Use unique_xmalloc_ptr in Python code This changes some utility functions in the Python code to return unique_xmalloc_ptr, and then fixes up the callers. I chose unique_xmalloc_ptr rather than std::string because at a few call points the xmalloc'd string is released and ownership transferred elsewhere. This patch found a few existing memory leaks. For example, py-unwind.c called gdbpy_obj_to_string but never freed the result. Built and regression tested on the buildbot. 2016-11-09 Tom Tromey <tom@tromey.com> * varobj.h (varobj_get_display_hint): Change return type. * varobj.c (varobj_get_display_hint): Return unique_xmalloc_ptr. (varobj_value_get_print_value): Update. * python/python.c (gdbpy_before_prompt_hook, gdbpy_print_stack) (gdbpy_apply_type_printers): Update. * python/python-internal.h (unicode_to_target_string) (python_string_to_target_string, python_string_to_host_string) (gdbpy_obj_to_string, gdbpy_exception_to_string) (gdbpy_get_display_hint): Change return types. * python/py-varobj.c (py_varobj_iter_next): Update. * python/py-value.c (valpy_getitem, convert_value_from_python): Update. * python/py-utils.c (unicode_to_encoded_string) (unicode_to_target_string, python_string_to_target_string) (python_string_to_host_string, gdbpy_obj_to_string) (gdbpy_exception_to_string): Return unique_xmalloc_ptr. * python/py-unwind.c (pyuw_parse_register_id): Update. * python/py-type.c (typy_getitem): Update. * python/py-prettyprint.c (gdbpy_get_display_hint) (print_stack_unless_memory_error, print_children) (gdbpy_apply_val_pretty_printer): Update. * python/py-param.c (set_parameter_value): Update. (get_doc_string, call_doc_function): Return unique_xmalloc_ptr. (get_set_value, get_show_value, compute_enum_values, parmpy_init): Update. * python/py-infthread.c (thpy_set_name): Update. * python/py-function.c (fnpy_call, fnpy_init): Update. * python/py-framefilter.c (extract_sym): Change "name" to unique_xmalloc_ptr. (enumerate_args, enumerate_locals): Update. (py_print_frame): Use unique_xmalloc_ptr. * python/py-frame.c (frapy_read_var): Update. Remove cleanup. * python/py-cmd.c (cmdpy_function, cmdpy_completer, cmdpy_init): Update. * python/py-breakpoint.c (bppy_set_condition): Use unique_xmalloc_ptr. (bppy_init): Likewise. Remove cleanup. (local_setattro): Update. * mi/mi-cmd-var.c (print_varobj, mi_cmd_var_list_children) (varobj_update_one): Update.
2016-10-15 09:20:02 -06:00
gdb::unique_xmalloc_ptr<char> show_doc_string;
gdbpy_enter enter_py;
gdbpy_ref<> show_doc_func (PyUnicode_FromString ("get_show_string"));
if (show_doc_func == NULL)
{
gdbpy_print_stack ();
return;
}
if (PyObject_HasAttr (obj, show_doc_func.get ()))
{
gdbpy_ref<> val_obj (PyUnicode_FromString (value));
if (val_obj == NULL)
{
gdbpy_print_stack ();
return;
}
show_doc_string = call_doc_function (obj, show_doc_func.get (),
val_obj.get ());
if (! show_doc_string)
{
gdbpy_print_stack ();
return;
}
gdb_printf (file, "%s\n", show_doc_string.get ());
}
else
{
gdb/python: improve the auto help text for gdb.Parameter This commit attempts to improve the help text that is generated for gdb.Parameter objects when the user fails to provide their own documentation. Documentation for a gdb.Parameter is currently pulled from two sources: the class documentation string, and the set_doc/show_doc class attributes. Thus, a fully documented parameter might look like this: class Param_All (gdb.Parameter): """This is the class documentation string.""" show_doc = "Show the state of this parameter" set_doc = "Set the state of this parameter" def get_set_string (self): val = "on" if (self.value == False): val = "off" return "Test Parameter has been set to " + val def __init__ (self, name): super (Param_All, self).__init__ (name, gdb.COMMAND_DATA, gdb.PARAM_BOOLEAN) self._value = True Param_All ('param-all') Then in GDB we see this: (gdb) help set param-all Set the state of this parameter This is the class documentation string. Which is fine. But, if the user skips both of the documentation parts like this: class Param_None (gdb.Parameter): def get_set_string (self): val = "on" if (self.value == False): val = "off" return "Test Parameter has been set to " + val def __init__ (self, name): super (Param_None, self).__init__ (name, gdb.COMMAND_DATA, gdb.PARAM_BOOLEAN) self._value = True Param_None ('param-none') Now in GDB we see this: (gdb) help set param-none This command is not documented. This command is not documented. That's not great, the duplicated text looks a bit weird. If we drop different parts we get different results. Here's what we get if the user drops the set_doc and show_doc attributes: (gdb) help set param-doc This command is not documented. This is the class documentation string. That kind of sucks, we say it's undocumented, then proceed to print the documentation. Finally, if we drop the class documentation but keep the set_doc and show_doc: (gdb) help set param-set-show Set the state of this parameter This command is not documented. That seems OK. So, I think there's room for improvement. With this patch, for the four cases above we now see this: # All values provided by the user, no change in this case: (gdb) help set param-all Set the state of this parameter This is the class documentation string. # Nothing provided by the user, the first string is now different: (gdb) help set param-none Set the current value of 'param-none'. This command is not documented. # Only the class documentation is provided, the first string is # changed as in the previous case: (gdb) help set param-doc Set the current value of 'param-doc'. This is the class documentation string. # Only the set_doc and show_doc are provided, this case is unchanged # from before the patch: (gdb) help set param-set-show Set the state of this parameter This command is not documented. The one place where this change might be considered a negative is when dealing with prefix commands. If we create a prefix command but don't supply the set_doc / show_doc strings, then this is what we saw before my patch: (gdb) python Param_None ('print param-none') (gdb) help set print set print, set pr, set p Generic command for setting how things print. List of set print subcommands: ... snip ... set print param-none -- This command is not documented. ... snip ... And after my patch: (gdb) python Param_None ('print param-none') (gdb) help set print set print, set pr, set p Generic command for setting how things print. List of set print subcommands: ... snip ... set print param-none -- Set the current value of 'print param-none'. ... snip ... This seems slightly less helpful than before, but I don't think its terrible. Additionally, I've changed what we print when the get_show_string method is not provided in Python. Back when gdb.Parameter was first added to GDB, we didn't provide a show function when registering the internal command object within GDB. As a result, GDB would make use of its "magic" mangling of the show_doc string to create a sentence that would display the current value (see deprecated_show_value_hack in cli/cli-setshow.c). However, when we added support for the get_show_string method to gdb.Parameter, there was an attempt to maintain backward compatibility by displaying the show_doc string with the current value appended, see get_show_value in py-param.c. Unfortunately, this isn't anywhere close to what deprecated_show_value_hack does, and the results are pretty poor, for example, this is GDB before my patch: (gdb) show param-none This command is not documented. off I think we can all agree that this is pretty bad. After my patch, we how show this: (gdb) show param-none The current value of 'param-none' is "off". Which at least is a real sentence, even if it's not very informative. This patch does change the way that the Python API behaves slightly, but only in the cases when the user has missed providing GDB with some information. In most cases I think the new behaviour is a lot better, there's the one case (noted above) which is a bit iffy, but I think is still OK. I've updated the existing gdb.python/py-parameter.exp test to cover the modified behaviour. Finally, I've updated the documentation to (I hope) make it clearer how the various bits of help text come together.
2022-01-07 16:48:49 +00:00
/* If there is no 'get_show_string' callback then we want to show
something sensible here. In older versions of GDB (< 7.3) we
didn't support 'get_show_string', and instead we just made use of
GDB's builtin use of the show_doc. However, GDB's builtin
show_doc adjustment is not i18n friendly, so, instead, we just
print this generic string. */
std::string cmd_path = full_cmd_name_without_first_prefix (c);
gdb_printf (file, _("The current value of '%s' is \"%s\".\n"),
cmd_path.c_str (), value);
}
}
/* A helper function that dispatches to the appropriate add_setshow
function. */
static void
GDB: Allow arbitrary keywords in integer set commands Rather than just `unlimited' allow the integer set commands (or command options) to define arbitrary keywords for the user to use, removing hardcoded arrangements for the `unlimited' keyword. Remove the confusingly named `var_zinteger', `var_zuinteger' and `var_zuinteger_unlimited' `set'/`show' command variable types redefining them in terms of `var_uinteger', `var_integer' and `var_pinteger', which have the range of [0;UINT_MAX], [INT_MIN;INT_MAX], and [0;INT_MAX] each. Following existing practice `var_pinteger' allows extra negative values to be used, however unlike `var_zuinteger_unlimited' any number of such values can be defined rather than just `-1'. The "p" in `var_pinteger' stands for "positive", for the lack of a more appropriate unambiguous letter, even though 0 obviously is not positive; "n" would be confusing as to whether it stands for "non-negative" or "negative". Add a new structure, `literal_def', the entries of which define extra keywords allowed for a command and numerical values they correspond to. Those values are not verified against the basic range supported by the underlying variable type, allowing extra values to be allowed outside that range, which may or may not be individually made visible to the user. An optional value translation is possible with the structure to follow the existing practice for some commands where user-entered 0 is internally translated to UINT_MAX or INT_MAX. Such translation can now be arbitrary. Literals defined by this structure are automatically used for completion as necessary. So for example: const literal_def integer_unlimited_literals[] = { { "unlimited", INT_MAX, 0 }, { nullptr } }; defines an extra `unlimited' keyword and a user-visible 0 value, both of which get translated to INT_MAX for the setting to be used with. Similarly: const literal_def zuinteger_unlimited_literals[] = { { "unlimited", -1, -1 }, { nullptr } }; defines the same keyword and a corresponding user-visible -1 value that is used for the requested setting. If the last member were omitted (or set to `{}') here, then only the keyword would be allowed for the user to enter and while -1 would still be used internally trying to enter it as a part of a command would result in an "integer -1 out of range" error. Use said error message in all cases (citing the invalid value requested) replacing "only -1 is allowed to set as unlimited" previously used for `var_zuinteger_unlimited' settings only rather than propagating it to `var_pinteger' type. It could only be used for the specific case where a single extra `unlimited' keyword was defined standing for -1 and the use of numeric equivalents is discouraged anyway as it is for historical reasons only that they expose GDB internals, confusingly different across variable types. Similarly update the "must be >= -1" Guile error message. Redefine Guile and Python parameter types in terms of the new variable types and interpret extra keywords as Scheme keywords and Python strings used to communicate corresponding parameter values. Do not add a new PARAM_INTEGER Guile parameter type, however do handle the `var_integer' variable type now, permitting existing parameters defined by GDB proper, such as `listsize', to be accessed from Scheme code. With these changes in place it should be trivial for a Scheme or Python programmer to expand the syntax of the `make-parameter' command and the `gdb.Parameter' class initializer to have arbitrary extra literals along with their internal representation supplied. Update the testsuite accordingly. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-19 21:15:56 +00:00
add_setshow_generic (enum var_types type, const literal_def *extra_literals,
enum command_class cmdclass,
gdb::unique_xmalloc_ptr<char> cmd_name,
parmpy_object *self,
const char *set_doc, const char *show_doc,
const char *help_doc,
struct cmd_list_element **set_list,
struct cmd_list_element **show_list)
{
set_show_commands commands;
GDB: Allow arbitrary keywords in integer set commands Rather than just `unlimited' allow the integer set commands (or command options) to define arbitrary keywords for the user to use, removing hardcoded arrangements for the `unlimited' keyword. Remove the confusingly named `var_zinteger', `var_zuinteger' and `var_zuinteger_unlimited' `set'/`show' command variable types redefining them in terms of `var_uinteger', `var_integer' and `var_pinteger', which have the range of [0;UINT_MAX], [INT_MIN;INT_MAX], and [0;INT_MAX] each. Following existing practice `var_pinteger' allows extra negative values to be used, however unlike `var_zuinteger_unlimited' any number of such values can be defined rather than just `-1'. The "p" in `var_pinteger' stands for "positive", for the lack of a more appropriate unambiguous letter, even though 0 obviously is not positive; "n" would be confusing as to whether it stands for "non-negative" or "negative". Add a new structure, `literal_def', the entries of which define extra keywords allowed for a command and numerical values they correspond to. Those values are not verified against the basic range supported by the underlying variable type, allowing extra values to be allowed outside that range, which may or may not be individually made visible to the user. An optional value translation is possible with the structure to follow the existing practice for some commands where user-entered 0 is internally translated to UINT_MAX or INT_MAX. Such translation can now be arbitrary. Literals defined by this structure are automatically used for completion as necessary. So for example: const literal_def integer_unlimited_literals[] = { { "unlimited", INT_MAX, 0 }, { nullptr } }; defines an extra `unlimited' keyword and a user-visible 0 value, both of which get translated to INT_MAX for the setting to be used with. Similarly: const literal_def zuinteger_unlimited_literals[] = { { "unlimited", -1, -1 }, { nullptr } }; defines the same keyword and a corresponding user-visible -1 value that is used for the requested setting. If the last member were omitted (or set to `{}') here, then only the keyword would be allowed for the user to enter and while -1 would still be used internally trying to enter it as a part of a command would result in an "integer -1 out of range" error. Use said error message in all cases (citing the invalid value requested) replacing "only -1 is allowed to set as unlimited" previously used for `var_zuinteger_unlimited' settings only rather than propagating it to `var_pinteger' type. It could only be used for the specific case where a single extra `unlimited' keyword was defined standing for -1 and the use of numeric equivalents is discouraged anyway as it is for historical reasons only that they expose GDB internals, confusingly different across variable types. Similarly update the "must be >= -1" Guile error message. Redefine Guile and Python parameter types in terms of the new variable types and interpret extra keywords as Scheme keywords and Python strings used to communicate corresponding parameter values. Do not add a new PARAM_INTEGER Guile parameter type, however do handle the `var_integer' variable type now, permitting existing parameters defined by GDB proper, such as `listsize', to be accessed from Scheme code. With these changes in place it should be trivial for a Scheme or Python programmer to expand the syntax of the `make-parameter' command and the `gdb.Parameter' class initializer to have arbitrary extra literals along with their internal representation supplied. Update the testsuite accordingly. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-19 21:15:56 +00:00
switch (type)
{
case var_boolean:
commands = add_setshow_boolean_cmd (cmd_name.get (), cmdclass,
&self->value.boolval, set_doc,
show_doc, help_doc, get_set_value,
get_show_value, set_list, show_list);
break;
case var_auto_boolean:
commands = add_setshow_auto_boolean_cmd (cmd_name.get (), cmdclass,
&self->value.autoboolval,
set_doc, show_doc, help_doc,
get_set_value, get_show_value,
set_list, show_list);
break;
case var_uinteger:
commands = add_setshow_uinteger_cmd (cmd_name.get (), cmdclass,
GDB: Allow arbitrary keywords in integer set commands Rather than just `unlimited' allow the integer set commands (or command options) to define arbitrary keywords for the user to use, removing hardcoded arrangements for the `unlimited' keyword. Remove the confusingly named `var_zinteger', `var_zuinteger' and `var_zuinteger_unlimited' `set'/`show' command variable types redefining them in terms of `var_uinteger', `var_integer' and `var_pinteger', which have the range of [0;UINT_MAX], [INT_MIN;INT_MAX], and [0;INT_MAX] each. Following existing practice `var_pinteger' allows extra negative values to be used, however unlike `var_zuinteger_unlimited' any number of such values can be defined rather than just `-1'. The "p" in `var_pinteger' stands for "positive", for the lack of a more appropriate unambiguous letter, even though 0 obviously is not positive; "n" would be confusing as to whether it stands for "non-negative" or "negative". Add a new structure, `literal_def', the entries of which define extra keywords allowed for a command and numerical values they correspond to. Those values are not verified against the basic range supported by the underlying variable type, allowing extra values to be allowed outside that range, which may or may not be individually made visible to the user. An optional value translation is possible with the structure to follow the existing practice for some commands where user-entered 0 is internally translated to UINT_MAX or INT_MAX. Such translation can now be arbitrary. Literals defined by this structure are automatically used for completion as necessary. So for example: const literal_def integer_unlimited_literals[] = { { "unlimited", INT_MAX, 0 }, { nullptr } }; defines an extra `unlimited' keyword and a user-visible 0 value, both of which get translated to INT_MAX for the setting to be used with. Similarly: const literal_def zuinteger_unlimited_literals[] = { { "unlimited", -1, -1 }, { nullptr } }; defines the same keyword and a corresponding user-visible -1 value that is used for the requested setting. If the last member were omitted (or set to `{}') here, then only the keyword would be allowed for the user to enter and while -1 would still be used internally trying to enter it as a part of a command would result in an "integer -1 out of range" error. Use said error message in all cases (citing the invalid value requested) replacing "only -1 is allowed to set as unlimited" previously used for `var_zuinteger_unlimited' settings only rather than propagating it to `var_pinteger' type. It could only be used for the specific case where a single extra `unlimited' keyword was defined standing for -1 and the use of numeric equivalents is discouraged anyway as it is for historical reasons only that they expose GDB internals, confusingly different across variable types. Similarly update the "must be >= -1" Guile error message. Redefine Guile and Python parameter types in terms of the new variable types and interpret extra keywords as Scheme keywords and Python strings used to communicate corresponding parameter values. Do not add a new PARAM_INTEGER Guile parameter type, however do handle the `var_integer' variable type now, permitting existing parameters defined by GDB proper, such as `listsize', to be accessed from Scheme code. With these changes in place it should be trivial for a Scheme or Python programmer to expand the syntax of the `make-parameter' command and the `gdb.Parameter' class initializer to have arbitrary extra literals along with their internal representation supplied. Update the testsuite accordingly. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-19 21:15:56 +00:00
&self->value.uintval,
extra_literals, set_doc,
show_doc, help_doc, get_set_value,
get_show_value, set_list, show_list);
break;
case var_integer:
commands = add_setshow_integer_cmd (cmd_name.get (), cmdclass,
GDB: Allow arbitrary keywords in integer set commands Rather than just `unlimited' allow the integer set commands (or command options) to define arbitrary keywords for the user to use, removing hardcoded arrangements for the `unlimited' keyword. Remove the confusingly named `var_zinteger', `var_zuinteger' and `var_zuinteger_unlimited' `set'/`show' command variable types redefining them in terms of `var_uinteger', `var_integer' and `var_pinteger', which have the range of [0;UINT_MAX], [INT_MIN;INT_MAX], and [0;INT_MAX] each. Following existing practice `var_pinteger' allows extra negative values to be used, however unlike `var_zuinteger_unlimited' any number of such values can be defined rather than just `-1'. The "p" in `var_pinteger' stands for "positive", for the lack of a more appropriate unambiguous letter, even though 0 obviously is not positive; "n" would be confusing as to whether it stands for "non-negative" or "negative". Add a new structure, `literal_def', the entries of which define extra keywords allowed for a command and numerical values they correspond to. Those values are not verified against the basic range supported by the underlying variable type, allowing extra values to be allowed outside that range, which may or may not be individually made visible to the user. An optional value translation is possible with the structure to follow the existing practice for some commands where user-entered 0 is internally translated to UINT_MAX or INT_MAX. Such translation can now be arbitrary. Literals defined by this structure are automatically used for completion as necessary. So for example: const literal_def integer_unlimited_literals[] = { { "unlimited", INT_MAX, 0 }, { nullptr } }; defines an extra `unlimited' keyword and a user-visible 0 value, both of which get translated to INT_MAX for the setting to be used with. Similarly: const literal_def zuinteger_unlimited_literals[] = { { "unlimited", -1, -1 }, { nullptr } }; defines the same keyword and a corresponding user-visible -1 value that is used for the requested setting. If the last member were omitted (or set to `{}') here, then only the keyword would be allowed for the user to enter and while -1 would still be used internally trying to enter it as a part of a command would result in an "integer -1 out of range" error. Use said error message in all cases (citing the invalid value requested) replacing "only -1 is allowed to set as unlimited" previously used for `var_zuinteger_unlimited' settings only rather than propagating it to `var_pinteger' type. It could only be used for the specific case where a single extra `unlimited' keyword was defined standing for -1 and the use of numeric equivalents is discouraged anyway as it is for historical reasons only that they expose GDB internals, confusingly different across variable types. Similarly update the "must be >= -1" Guile error message. Redefine Guile and Python parameter types in terms of the new variable types and interpret extra keywords as Scheme keywords and Python strings used to communicate corresponding parameter values. Do not add a new PARAM_INTEGER Guile parameter type, however do handle the `var_integer' variable type now, permitting existing parameters defined by GDB proper, such as `listsize', to be accessed from Scheme code. With these changes in place it should be trivial for a Scheme or Python programmer to expand the syntax of the `make-parameter' command and the `gdb.Parameter' class initializer to have arbitrary extra literals along with their internal representation supplied. Update the testsuite accordingly. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-19 21:15:56 +00:00
&self->value.intval,
extra_literals, set_doc,
show_doc, help_doc, get_set_value,
get_show_value, set_list, show_list);
break;
GDB: Allow arbitrary keywords in integer set commands Rather than just `unlimited' allow the integer set commands (or command options) to define arbitrary keywords for the user to use, removing hardcoded arrangements for the `unlimited' keyword. Remove the confusingly named `var_zinteger', `var_zuinteger' and `var_zuinteger_unlimited' `set'/`show' command variable types redefining them in terms of `var_uinteger', `var_integer' and `var_pinteger', which have the range of [0;UINT_MAX], [INT_MIN;INT_MAX], and [0;INT_MAX] each. Following existing practice `var_pinteger' allows extra negative values to be used, however unlike `var_zuinteger_unlimited' any number of such values can be defined rather than just `-1'. The "p" in `var_pinteger' stands for "positive", for the lack of a more appropriate unambiguous letter, even though 0 obviously is not positive; "n" would be confusing as to whether it stands for "non-negative" or "negative". Add a new structure, `literal_def', the entries of which define extra keywords allowed for a command and numerical values they correspond to. Those values are not verified against the basic range supported by the underlying variable type, allowing extra values to be allowed outside that range, which may or may not be individually made visible to the user. An optional value translation is possible with the structure to follow the existing practice for some commands where user-entered 0 is internally translated to UINT_MAX or INT_MAX. Such translation can now be arbitrary. Literals defined by this structure are automatically used for completion as necessary. So for example: const literal_def integer_unlimited_literals[] = { { "unlimited", INT_MAX, 0 }, { nullptr } }; defines an extra `unlimited' keyword and a user-visible 0 value, both of which get translated to INT_MAX for the setting to be used with. Similarly: const literal_def zuinteger_unlimited_literals[] = { { "unlimited", -1, -1 }, { nullptr } }; defines the same keyword and a corresponding user-visible -1 value that is used for the requested setting. If the last member were omitted (or set to `{}') here, then only the keyword would be allowed for the user to enter and while -1 would still be used internally trying to enter it as a part of a command would result in an "integer -1 out of range" error. Use said error message in all cases (citing the invalid value requested) replacing "only -1 is allowed to set as unlimited" previously used for `var_zuinteger_unlimited' settings only rather than propagating it to `var_pinteger' type. It could only be used for the specific case where a single extra `unlimited' keyword was defined standing for -1 and the use of numeric equivalents is discouraged anyway as it is for historical reasons only that they expose GDB internals, confusingly different across variable types. Similarly update the "must be >= -1" Guile error message. Redefine Guile and Python parameter types in terms of the new variable types and interpret extra keywords as Scheme keywords and Python strings used to communicate corresponding parameter values. Do not add a new PARAM_INTEGER Guile parameter type, however do handle the `var_integer' variable type now, permitting existing parameters defined by GDB proper, such as `listsize', to be accessed from Scheme code. With these changes in place it should be trivial for a Scheme or Python programmer to expand the syntax of the `make-parameter' command and the `gdb.Parameter' class initializer to have arbitrary extra literals along with their internal representation supplied. Update the testsuite accordingly. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-19 21:15:56 +00:00
case var_pinteger:
commands = add_setshow_pinteger_cmd (cmd_name.get (), cmdclass,
&self->value.intval,
extra_literals, set_doc,
show_doc, help_doc, get_set_value,
get_show_value, set_list, show_list);
break;
case var_string:
commands = add_setshow_string_cmd (cmd_name.get (), cmdclass,
gdb: make string-like set show commands use std::string variable String-like settings (var_string, var_filename, var_optional_filename, var_string_noescape) currently take a pointer to a `char *` storage variable (typically global) that holds the setting's value. I'd like to "mordernize" this by changing them to use an std::string for storage. An obvious reason is that string operations on std::string are often easier to write than with C strings. And they avoid having to do any manual memory management. Another interesting reason is that, with `char *`, nullptr and an empty string often both have the same meaning of "no value". String settings are initially nullptr (unless initialized otherwise). But when doing "set foo" (where `foo` is a string setting), the setting now points to an empty string. For example, solib_search_path is nullptr at startup, but points to an empty string after doing "set solib-search-path". This leads to some code that needs to check for both to check for "no value". Or some code that converts back and forth between NULL and "" when getting or setting the value. I find this very error-prone, because it is very easy to forget one or the other. With std::string, we at least know that the variable is not "NULL". There is only one way of representing an empty string setting, that is with an empty string. I was wondering whether the distinction between NULL and "" would be important for some setting, but it doesn't seem so. If that ever happens, it would be more C++-y and self-descriptive to use optional<string> anyway. Actually, there's one spot where this distinction mattered, it's in init_history, for the test gdb.base/gdbinit-history.exp. init_history sets the history filename to the default ".gdb_history" if it sees that the setting was never set - if history_filename is nullptr. If history_filename is an empty string, it means the setting was explicitly cleared, so it leaves it as-is. With the change to std::string, this distinction doesn't exist anymore. This can be fixed by moving the code that chooses a good default value for history_filename to _initialize_top. This is ran before -ex commands are processed, so an -ex command can then clear that value if needed (what gdb.base/gdbinit-history.exp tests). Another small improvement, in my opinion is that we can now easily give string parameters initial values, by simply initializing the global variables, instead of xstrdup-ing it in the _initialize function. In Python and Guile, when registering a string-like parameter, we allocate (with new) an std::string that is owned by the param_smob (in Guile) and the parmpy_object (in Python) objects. This patch started by changing all relevant add_setshow_* commands to take an `std::string *` instead of a `char **` and fixing everything that failed to build. That includes of course all string setting variable and their uses. string_option_def now uses an std::string also, because there's a connection between options and settings (see add_setshow_cmds_for_options). The add_path function in source.c is really complex and twisted, I'd rather not try to change it to work on an std::string right now. Instead, I added an overload that copies the std:string to a `char *` and back. This means more copying, but this is not used in a hot path at all, so I think it is acceptable. Change-Id: I92c50a1bdd8307141cdbacb388248e4e4fc08c93 Co-authored-by: Lancelot SIX <lsix@lancelotsix.com>
2021-09-10 17:10:13 -04:00
self->value.stringval, set_doc,
show_doc, help_doc, get_set_value,
get_show_value, set_list, show_list);
break;
case var_string_noescape:
commands = add_setshow_string_noescape_cmd (cmd_name.get (), cmdclass,
gdb: make string-like set show commands use std::string variable String-like settings (var_string, var_filename, var_optional_filename, var_string_noescape) currently take a pointer to a `char *` storage variable (typically global) that holds the setting's value. I'd like to "mordernize" this by changing them to use an std::string for storage. An obvious reason is that string operations on std::string are often easier to write than with C strings. And they avoid having to do any manual memory management. Another interesting reason is that, with `char *`, nullptr and an empty string often both have the same meaning of "no value". String settings are initially nullptr (unless initialized otherwise). But when doing "set foo" (where `foo` is a string setting), the setting now points to an empty string. For example, solib_search_path is nullptr at startup, but points to an empty string after doing "set solib-search-path". This leads to some code that needs to check for both to check for "no value". Or some code that converts back and forth between NULL and "" when getting or setting the value. I find this very error-prone, because it is very easy to forget one or the other. With std::string, we at least know that the variable is not "NULL". There is only one way of representing an empty string setting, that is with an empty string. I was wondering whether the distinction between NULL and "" would be important for some setting, but it doesn't seem so. If that ever happens, it would be more C++-y and self-descriptive to use optional<string> anyway. Actually, there's one spot where this distinction mattered, it's in init_history, for the test gdb.base/gdbinit-history.exp. init_history sets the history filename to the default ".gdb_history" if it sees that the setting was never set - if history_filename is nullptr. If history_filename is an empty string, it means the setting was explicitly cleared, so it leaves it as-is. With the change to std::string, this distinction doesn't exist anymore. This can be fixed by moving the code that chooses a good default value for history_filename to _initialize_top. This is ran before -ex commands are processed, so an -ex command can then clear that value if needed (what gdb.base/gdbinit-history.exp tests). Another small improvement, in my opinion is that we can now easily give string parameters initial values, by simply initializing the global variables, instead of xstrdup-ing it in the _initialize function. In Python and Guile, when registering a string-like parameter, we allocate (with new) an std::string that is owned by the param_smob (in Guile) and the parmpy_object (in Python) objects. This patch started by changing all relevant add_setshow_* commands to take an `std::string *` instead of a `char **` and fixing everything that failed to build. That includes of course all string setting variable and their uses. string_option_def now uses an std::string also, because there's a connection between options and settings (see add_setshow_cmds_for_options). The add_path function in source.c is really complex and twisted, I'd rather not try to change it to work on an std::string right now. Instead, I added an overload that copies the std:string to a `char *` and back. This means more copying, but this is not used in a hot path at all, so I think it is acceptable. Change-Id: I92c50a1bdd8307141cdbacb388248e4e4fc08c93 Co-authored-by: Lancelot SIX <lsix@lancelotsix.com>
2021-09-10 17:10:13 -04:00
self->value.stringval,
set_doc, show_doc, help_doc,
get_set_value, get_show_value,
set_list, show_list);
break;
case var_optional_filename:
commands = add_setshow_optional_filename_cmd (cmd_name.get (), cmdclass,
gdb: make string-like set show commands use std::string variable String-like settings (var_string, var_filename, var_optional_filename, var_string_noescape) currently take a pointer to a `char *` storage variable (typically global) that holds the setting's value. I'd like to "mordernize" this by changing them to use an std::string for storage. An obvious reason is that string operations on std::string are often easier to write than with C strings. And they avoid having to do any manual memory management. Another interesting reason is that, with `char *`, nullptr and an empty string often both have the same meaning of "no value". String settings are initially nullptr (unless initialized otherwise). But when doing "set foo" (where `foo` is a string setting), the setting now points to an empty string. For example, solib_search_path is nullptr at startup, but points to an empty string after doing "set solib-search-path". This leads to some code that needs to check for both to check for "no value". Or some code that converts back and forth between NULL and "" when getting or setting the value. I find this very error-prone, because it is very easy to forget one or the other. With std::string, we at least know that the variable is not "NULL". There is only one way of representing an empty string setting, that is with an empty string. I was wondering whether the distinction between NULL and "" would be important for some setting, but it doesn't seem so. If that ever happens, it would be more C++-y and self-descriptive to use optional<string> anyway. Actually, there's one spot where this distinction mattered, it's in init_history, for the test gdb.base/gdbinit-history.exp. init_history sets the history filename to the default ".gdb_history" if it sees that the setting was never set - if history_filename is nullptr. If history_filename is an empty string, it means the setting was explicitly cleared, so it leaves it as-is. With the change to std::string, this distinction doesn't exist anymore. This can be fixed by moving the code that chooses a good default value for history_filename to _initialize_top. This is ran before -ex commands are processed, so an -ex command can then clear that value if needed (what gdb.base/gdbinit-history.exp tests). Another small improvement, in my opinion is that we can now easily give string parameters initial values, by simply initializing the global variables, instead of xstrdup-ing it in the _initialize function. In Python and Guile, when registering a string-like parameter, we allocate (with new) an std::string that is owned by the param_smob (in Guile) and the parmpy_object (in Python) objects. This patch started by changing all relevant add_setshow_* commands to take an `std::string *` instead of a `char **` and fixing everything that failed to build. That includes of course all string setting variable and their uses. string_option_def now uses an std::string also, because there's a connection between options and settings (see add_setshow_cmds_for_options). The add_path function in source.c is really complex and twisted, I'd rather not try to change it to work on an std::string right now. Instead, I added an overload that copies the std:string to a `char *` and back. This means more copying, but this is not used in a hot path at all, so I think it is acceptable. Change-Id: I92c50a1bdd8307141cdbacb388248e4e4fc08c93 Co-authored-by: Lancelot SIX <lsix@lancelotsix.com>
2021-09-10 17:10:13 -04:00
self->value.stringval,
set_doc, show_doc, help_doc,
get_set_value,
get_show_value, set_list,
show_list);
break;
case var_filename:
commands = add_setshow_filename_cmd (cmd_name.get (), cmdclass,
gdb: make string-like set show commands use std::string variable String-like settings (var_string, var_filename, var_optional_filename, var_string_noescape) currently take a pointer to a `char *` storage variable (typically global) that holds the setting's value. I'd like to "mordernize" this by changing them to use an std::string for storage. An obvious reason is that string operations on std::string are often easier to write than with C strings. And they avoid having to do any manual memory management. Another interesting reason is that, with `char *`, nullptr and an empty string often both have the same meaning of "no value". String settings are initially nullptr (unless initialized otherwise). But when doing "set foo" (where `foo` is a string setting), the setting now points to an empty string. For example, solib_search_path is nullptr at startup, but points to an empty string after doing "set solib-search-path". This leads to some code that needs to check for both to check for "no value". Or some code that converts back and forth between NULL and "" when getting or setting the value. I find this very error-prone, because it is very easy to forget one or the other. With std::string, we at least know that the variable is not "NULL". There is only one way of representing an empty string setting, that is with an empty string. I was wondering whether the distinction between NULL and "" would be important for some setting, but it doesn't seem so. If that ever happens, it would be more C++-y and self-descriptive to use optional<string> anyway. Actually, there's one spot where this distinction mattered, it's in init_history, for the test gdb.base/gdbinit-history.exp. init_history sets the history filename to the default ".gdb_history" if it sees that the setting was never set - if history_filename is nullptr. If history_filename is an empty string, it means the setting was explicitly cleared, so it leaves it as-is. With the change to std::string, this distinction doesn't exist anymore. This can be fixed by moving the code that chooses a good default value for history_filename to _initialize_top. This is ran before -ex commands are processed, so an -ex command can then clear that value if needed (what gdb.base/gdbinit-history.exp tests). Another small improvement, in my opinion is that we can now easily give string parameters initial values, by simply initializing the global variables, instead of xstrdup-ing it in the _initialize function. In Python and Guile, when registering a string-like parameter, we allocate (with new) an std::string that is owned by the param_smob (in Guile) and the parmpy_object (in Python) objects. This patch started by changing all relevant add_setshow_* commands to take an `std::string *` instead of a `char **` and fixing everything that failed to build. That includes of course all string setting variable and their uses. string_option_def now uses an std::string also, because there's a connection between options and settings (see add_setshow_cmds_for_options). The add_path function in source.c is really complex and twisted, I'd rather not try to change it to work on an std::string right now. Instead, I added an overload that copies the std:string to a `char *` and back. This means more copying, but this is not used in a hot path at all, so I think it is acceptable. Change-Id: I92c50a1bdd8307141cdbacb388248e4e4fc08c93 Co-authored-by: Lancelot SIX <lsix@lancelotsix.com>
2021-09-10 17:10:13 -04:00
self->value.stringval, set_doc,
show_doc, help_doc, get_set_value,
get_show_value, set_list, show_list);
break;
case var_enum:
/* Initialize the value, just in case. */
self->value.cstringval = self->enumeration[0];
commands = add_setshow_enum_cmd (cmd_name.get (), cmdclass,
self->enumeration,
&self->value.cstringval, set_doc,
show_doc, help_doc, get_set_value,
get_show_value, set_list, show_list);
break;
case var_color:
/* Initialize the value, just in case. */
self->value.color = ui_file_style::NONE;
commands = add_setshow_color_cmd (cmd_name.get (), cmdclass,
&self->value.color, set_doc,
show_doc, help_doc, get_set_value,
get_show_value, set_list, show_list);
break;
default:
gdb_assert_not_reached ("Unhandled parameter class.");
}
/* Register Python objects in both commands' context. */
commands.set->set_context (self);
commands.show->set_context (self);
/* We (unfortunately) currently leak the command name. */
cmd_name.release ();
}
gdb/ * python/py-breakpoint.c (bppy_set_condition): New comment. * python/py-cmd.c (cmdpy_function): Call also gdbpy_print_stack for failed PyUnicode_Decode. (cmdpy_completer): Skip element for failed python_string_to_host_string. (cmdpy_init): Return -1 on failed python_string_to_host_string. * python/py-frame.c (frapy_read_var): Extend the function comment. * python/py-function.c (fnpy_init): Return -1 on failed python_string_to_host_string. * python/py-inferior.c (infpy_read_memory, infpy_write_memory): Extend the function comment. (infpy_search_memory): Extend the function comment. Remove the PyErr_SetString call on already set error state. * python/py-param.c (set_parameter_value): Extend the function comment. Return -1 on failed python_string_to_host_string, twice. (set_attr): Extend the function comment. (compute_enum_values): Extend the function comment. New variable back_to. Protect self->enumeration by BACK_TO cleanups. Return 0 on failed python_string_to_host_string. (get_doc_string): Call gdbpy_print_stack on failed python_string_to_host_string. (parmpy_init): Extend the function comment. * python/py-prettyprint.c (pretty_print_one_value): Likewise. (gdbpy_get_display_hint, print_children): Call gdbpy_print_stack on failed python_string_to_host_string. * python/py-value.c (valpy_new, valpy_getitem, valpy_call) (valpy_binop, valpy_richcompare): Extend the function comment. * python/python.c (struct python_env) <error_type, error_value, error_traceback>: New fields. (restore_python_env): Handle PyErr_Occurred. Call PyErr_Restore. (ensure_python_env): Call PyErr_Fetch. * varobj.c (update_dynamic_varobj_children): Call gdbpy_print_stack on failed convert_value_from_python. (value_get_print_value): Call gdbpy_print_stack on failed python_string_to_target_python_string. gdb/testsuite/ * gdb.python/py-error.exp: New file. * gdb.python/py-error.py: New file.
2010-10-13 13:24:40 +00:00
/* A helper which computes enum values. Returns 1 on success. Returns 0 on
error, with a python exception set. */
static int
compute_enum_values (parmpy_object *self, PyObject *enum_values)
{
Py_ssize_t size, i;
if (! enum_values)
{
PyErr_SetString (PyExc_RuntimeError,
_("An enumeration is required for PARAM_ENUM."));
return 0;
}
if (! PySequence_Check (enum_values))
{
PyErr_SetString (PyExc_RuntimeError,
_("The enumeration is not a sequence."));
return 0;
}
size = PySequence_Size (enum_values);
if (size < 0)
return 0;
if (size == 0)
{
PyErr_SetString (PyExc_RuntimeError,
_("The enumeration is empty."));
return 0;
}
gdb_argv holder (XCNEWVEC (char *, size + 1));
char **enumeration = holder.get ();
for (i = 0; i < size; ++i)
{
gdbpy_ref<> item (PySequence_GetItem (enum_values, i));
if (item == NULL)
return 0;
if (! gdbpy_is_string (item.get ()))
{
PyErr_SetString (PyExc_RuntimeError,
_("The enumeration item not a string."));
return 0;
}
enumeration[i] = python_string_to_host_string (item.get ()).release ();
if (enumeration[i] == NULL)
return 0;
}
self->enumeration = const_cast<const char**> (holder.release ());
return 1;
}
/* Object initializer; sets up gdb-side structures for command.
Use: __init__(NAME, CMDCLASS, PARMCLASS, [ENUM])
NAME is the name of the parameter. 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.
CMDCLASS is the kind of command. It should be one of the COMMAND_*
constants defined in the gdb module.
PARMCLASS is the type of the parameter. It should be one of the
PARAM_* constants defined in the gdb module.
If PARMCLASS is PARAM_ENUM, then the final argument should be a
collection of strings. These strings are the valid values for this
parameter.
The documentation for the parameter is taken from the doc string
for the python class.
gdb/ * python/py-breakpoint.c (bppy_set_condition): New comment. * python/py-cmd.c (cmdpy_function): Call also gdbpy_print_stack for failed PyUnicode_Decode. (cmdpy_completer): Skip element for failed python_string_to_host_string. (cmdpy_init): Return -1 on failed python_string_to_host_string. * python/py-frame.c (frapy_read_var): Extend the function comment. * python/py-function.c (fnpy_init): Return -1 on failed python_string_to_host_string. * python/py-inferior.c (infpy_read_memory, infpy_write_memory): Extend the function comment. (infpy_search_memory): Extend the function comment. Remove the PyErr_SetString call on already set error state. * python/py-param.c (set_parameter_value): Extend the function comment. Return -1 on failed python_string_to_host_string, twice. (set_attr): Extend the function comment. (compute_enum_values): Extend the function comment. New variable back_to. Protect self->enumeration by BACK_TO cleanups. Return 0 on failed python_string_to_host_string. (get_doc_string): Call gdbpy_print_stack on failed python_string_to_host_string. (parmpy_init): Extend the function comment. * python/py-prettyprint.c (pretty_print_one_value): Likewise. (gdbpy_get_display_hint, print_children): Call gdbpy_print_stack on failed python_string_to_host_string. * python/py-value.c (valpy_new, valpy_getitem, valpy_call) (valpy_binop, valpy_richcompare): Extend the function comment. * python/python.c (struct python_env) <error_type, error_value, error_traceback>: New fields. (restore_python_env): Handle PyErr_Occurred. Call PyErr_Restore. (ensure_python_env): Call PyErr_Fetch. * varobj.c (update_dynamic_varobj_children): Call gdbpy_print_stack on failed convert_value_from_python. (value_get_print_value): Call gdbpy_print_stack on failed python_string_to_target_python_string. gdb/testsuite/ * gdb.python/py-error.exp: New file. * gdb.python/py-error.py: New file.
2010-10-13 13:24:40 +00:00
Returns -1 on error, with a python exception set. */
static int
parmpy_init (PyObject *self, PyObject *args, PyObject *kwds)
{
parmpy_object *obj = (parmpy_object *) self;
const char *name;
gdb::unique_xmalloc_ptr<char> set_doc, show_doc, doc;
int parmclass, cmdtype;
PyObject *enum_values = NULL;
struct cmd_list_element **set_list, **show_list;
GDB: Allow arbitrary keywords in integer set commands Rather than just `unlimited' allow the integer set commands (or command options) to define arbitrary keywords for the user to use, removing hardcoded arrangements for the `unlimited' keyword. Remove the confusingly named `var_zinteger', `var_zuinteger' and `var_zuinteger_unlimited' `set'/`show' command variable types redefining them in terms of `var_uinteger', `var_integer' and `var_pinteger', which have the range of [0;UINT_MAX], [INT_MIN;INT_MAX], and [0;INT_MAX] each. Following existing practice `var_pinteger' allows extra negative values to be used, however unlike `var_zuinteger_unlimited' any number of such values can be defined rather than just `-1'. The "p" in `var_pinteger' stands for "positive", for the lack of a more appropriate unambiguous letter, even though 0 obviously is not positive; "n" would be confusing as to whether it stands for "non-negative" or "negative". Add a new structure, `literal_def', the entries of which define extra keywords allowed for a command and numerical values they correspond to. Those values are not verified against the basic range supported by the underlying variable type, allowing extra values to be allowed outside that range, which may or may not be individually made visible to the user. An optional value translation is possible with the structure to follow the existing practice for some commands where user-entered 0 is internally translated to UINT_MAX or INT_MAX. Such translation can now be arbitrary. Literals defined by this structure are automatically used for completion as necessary. So for example: const literal_def integer_unlimited_literals[] = { { "unlimited", INT_MAX, 0 }, { nullptr } }; defines an extra `unlimited' keyword and a user-visible 0 value, both of which get translated to INT_MAX for the setting to be used with. Similarly: const literal_def zuinteger_unlimited_literals[] = { { "unlimited", -1, -1 }, { nullptr } }; defines the same keyword and a corresponding user-visible -1 value that is used for the requested setting. If the last member were omitted (or set to `{}') here, then only the keyword would be allowed for the user to enter and while -1 would still be used internally trying to enter it as a part of a command would result in an "integer -1 out of range" error. Use said error message in all cases (citing the invalid value requested) replacing "only -1 is allowed to set as unlimited" previously used for `var_zuinteger_unlimited' settings only rather than propagating it to `var_pinteger' type. It could only be used for the specific case where a single extra `unlimited' keyword was defined standing for -1 and the use of numeric equivalents is discouraged anyway as it is for historical reasons only that they expose GDB internals, confusingly different across variable types. Similarly update the "must be >= -1" Guile error message. Redefine Guile and Python parameter types in terms of the new variable types and interpret extra keywords as Scheme keywords and Python strings used to communicate corresponding parameter values. Do not add a new PARAM_INTEGER Guile parameter type, however do handle the `var_integer' variable type now, permitting existing parameters defined by GDB proper, such as `listsize', to be accessed from Scheme code. With these changes in place it should be trivial for a Scheme or Python programmer to expand the syntax of the `make-parameter' command and the `gdb.Parameter' class initializer to have arbitrary extra literals along with their internal representation supplied. Update the testsuite accordingly. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-19 21:15:56 +00:00
const literal_def *extra_literals;
enum var_types type;
if (! PyArg_ParseTuple (args, "sii|O", &name, &cmdtype, &parmclass,
&enum_values))
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
&& cmdtype != class_maintenance)
{
PyErr_Format (PyExc_RuntimeError, _("Invalid command class argument."));
return -1;
}
if (parmclass != param_boolean
GDB: Allow arbitrary keywords in integer set commands Rather than just `unlimited' allow the integer set commands (or command options) to define arbitrary keywords for the user to use, removing hardcoded arrangements for the `unlimited' keyword. Remove the confusingly named `var_zinteger', `var_zuinteger' and `var_zuinteger_unlimited' `set'/`show' command variable types redefining them in terms of `var_uinteger', `var_integer' and `var_pinteger', which have the range of [0;UINT_MAX], [INT_MIN;INT_MAX], and [0;INT_MAX] each. Following existing practice `var_pinteger' allows extra negative values to be used, however unlike `var_zuinteger_unlimited' any number of such values can be defined rather than just `-1'. The "p" in `var_pinteger' stands for "positive", for the lack of a more appropriate unambiguous letter, even though 0 obviously is not positive; "n" would be confusing as to whether it stands for "non-negative" or "negative". Add a new structure, `literal_def', the entries of which define extra keywords allowed for a command and numerical values they correspond to. Those values are not verified against the basic range supported by the underlying variable type, allowing extra values to be allowed outside that range, which may or may not be individually made visible to the user. An optional value translation is possible with the structure to follow the existing practice for some commands where user-entered 0 is internally translated to UINT_MAX or INT_MAX. Such translation can now be arbitrary. Literals defined by this structure are automatically used for completion as necessary. So for example: const literal_def integer_unlimited_literals[] = { { "unlimited", INT_MAX, 0 }, { nullptr } }; defines an extra `unlimited' keyword and a user-visible 0 value, both of which get translated to INT_MAX for the setting to be used with. Similarly: const literal_def zuinteger_unlimited_literals[] = { { "unlimited", -1, -1 }, { nullptr } }; defines the same keyword and a corresponding user-visible -1 value that is used for the requested setting. If the last member were omitted (or set to `{}') here, then only the keyword would be allowed for the user to enter and while -1 would still be used internally trying to enter it as a part of a command would result in an "integer -1 out of range" error. Use said error message in all cases (citing the invalid value requested) replacing "only -1 is allowed to set as unlimited" previously used for `var_zuinteger_unlimited' settings only rather than propagating it to `var_pinteger' type. It could only be used for the specific case where a single extra `unlimited' keyword was defined standing for -1 and the use of numeric equivalents is discouraged anyway as it is for historical reasons only that they expose GDB internals, confusingly different across variable types. Similarly update the "must be >= -1" Guile error message. Redefine Guile and Python parameter types in terms of the new variable types and interpret extra keywords as Scheme keywords and Python strings used to communicate corresponding parameter values. Do not add a new PARAM_INTEGER Guile parameter type, however do handle the `var_integer' variable type now, permitting existing parameters defined by GDB proper, such as `listsize', to be accessed from Scheme code. With these changes in place it should be trivial for a Scheme or Python programmer to expand the syntax of the `make-parameter' command and the `gdb.Parameter' class initializer to have arbitrary extra literals along with their internal representation supplied. Update the testsuite accordingly. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-19 21:15:56 +00:00
&& parmclass != param_auto_boolean
&& parmclass != param_uinteger && parmclass != param_integer
&& parmclass != param_string && parmclass != param_string_noescape
&& parmclass != param_optional_filename && parmclass != param_filename
&& parmclass != param_zinteger && parmclass != param_zuinteger
&& parmclass != param_zuinteger_unlimited && parmclass != param_enum
&& parmclass != param_color)
{
PyErr_SetString (PyExc_RuntimeError,
_("Invalid parameter class argument."));
return -1;
}
GDB: Allow arbitrary keywords in integer set commands Rather than just `unlimited' allow the integer set commands (or command options) to define arbitrary keywords for the user to use, removing hardcoded arrangements for the `unlimited' keyword. Remove the confusingly named `var_zinteger', `var_zuinteger' and `var_zuinteger_unlimited' `set'/`show' command variable types redefining them in terms of `var_uinteger', `var_integer' and `var_pinteger', which have the range of [0;UINT_MAX], [INT_MIN;INT_MAX], and [0;INT_MAX] each. Following existing practice `var_pinteger' allows extra negative values to be used, however unlike `var_zuinteger_unlimited' any number of such values can be defined rather than just `-1'. The "p" in `var_pinteger' stands for "positive", for the lack of a more appropriate unambiguous letter, even though 0 obviously is not positive; "n" would be confusing as to whether it stands for "non-negative" or "negative". Add a new structure, `literal_def', the entries of which define extra keywords allowed for a command and numerical values they correspond to. Those values are not verified against the basic range supported by the underlying variable type, allowing extra values to be allowed outside that range, which may or may not be individually made visible to the user. An optional value translation is possible with the structure to follow the existing practice for some commands where user-entered 0 is internally translated to UINT_MAX or INT_MAX. Such translation can now be arbitrary. Literals defined by this structure are automatically used for completion as necessary. So for example: const literal_def integer_unlimited_literals[] = { { "unlimited", INT_MAX, 0 }, { nullptr } }; defines an extra `unlimited' keyword and a user-visible 0 value, both of which get translated to INT_MAX for the setting to be used with. Similarly: const literal_def zuinteger_unlimited_literals[] = { { "unlimited", -1, -1 }, { nullptr } }; defines the same keyword and a corresponding user-visible -1 value that is used for the requested setting. If the last member were omitted (or set to `{}') here, then only the keyword would be allowed for the user to enter and while -1 would still be used internally trying to enter it as a part of a command would result in an "integer -1 out of range" error. Use said error message in all cases (citing the invalid value requested) replacing "only -1 is allowed to set as unlimited" previously used for `var_zuinteger_unlimited' settings only rather than propagating it to `var_pinteger' type. It could only be used for the specific case where a single extra `unlimited' keyword was defined standing for -1 and the use of numeric equivalents is discouraged anyway as it is for historical reasons only that they expose GDB internals, confusingly different across variable types. Similarly update the "must be >= -1" Guile error message. Redefine Guile and Python parameter types in terms of the new variable types and interpret extra keywords as Scheme keywords and Python strings used to communicate corresponding parameter values. Do not add a new PARAM_INTEGER Guile parameter type, however do handle the `var_integer' variable type now, permitting existing parameters defined by GDB proper, such as `listsize', to be accessed from Scheme code. With these changes in place it should be trivial for a Scheme or Python programmer to expand the syntax of the `make-parameter' command and the `gdb.Parameter' class initializer to have arbitrary extra literals along with their internal representation supplied. Update the testsuite accordingly. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-19 21:15:56 +00:00
if (enum_values && parmclass != param_enum)
{
PyErr_SetString (PyExc_RuntimeError,
_("Only PARAM_ENUM accepts a fourth argument."));
return -1;
}
GDB: Allow arbitrary keywords in integer set commands Rather than just `unlimited' allow the integer set commands (or command options) to define arbitrary keywords for the user to use, removing hardcoded arrangements for the `unlimited' keyword. Remove the confusingly named `var_zinteger', `var_zuinteger' and `var_zuinteger_unlimited' `set'/`show' command variable types redefining them in terms of `var_uinteger', `var_integer' and `var_pinteger', which have the range of [0;UINT_MAX], [INT_MIN;INT_MAX], and [0;INT_MAX] each. Following existing practice `var_pinteger' allows extra negative values to be used, however unlike `var_zuinteger_unlimited' any number of such values can be defined rather than just `-1'. The "p" in `var_pinteger' stands for "positive", for the lack of a more appropriate unambiguous letter, even though 0 obviously is not positive; "n" would be confusing as to whether it stands for "non-negative" or "negative". Add a new structure, `literal_def', the entries of which define extra keywords allowed for a command and numerical values they correspond to. Those values are not verified against the basic range supported by the underlying variable type, allowing extra values to be allowed outside that range, which may or may not be individually made visible to the user. An optional value translation is possible with the structure to follow the existing practice for some commands where user-entered 0 is internally translated to UINT_MAX or INT_MAX. Such translation can now be arbitrary. Literals defined by this structure are automatically used for completion as necessary. So for example: const literal_def integer_unlimited_literals[] = { { "unlimited", INT_MAX, 0 }, { nullptr } }; defines an extra `unlimited' keyword and a user-visible 0 value, both of which get translated to INT_MAX for the setting to be used with. Similarly: const literal_def zuinteger_unlimited_literals[] = { { "unlimited", -1, -1 }, { nullptr } }; defines the same keyword and a corresponding user-visible -1 value that is used for the requested setting. If the last member were omitted (or set to `{}') here, then only the keyword would be allowed for the user to enter and while -1 would still be used internally trying to enter it as a part of a command would result in an "integer -1 out of range" error. Use said error message in all cases (citing the invalid value requested) replacing "only -1 is allowed to set as unlimited" previously used for `var_zuinteger_unlimited' settings only rather than propagating it to `var_pinteger' type. It could only be used for the specific case where a single extra `unlimited' keyword was defined standing for -1 and the use of numeric equivalents is discouraged anyway as it is for historical reasons only that they expose GDB internals, confusingly different across variable types. Similarly update the "must be >= -1" Guile error message. Redefine Guile and Python parameter types in terms of the new variable types and interpret extra keywords as Scheme keywords and Python strings used to communicate corresponding parameter values. Do not add a new PARAM_INTEGER Guile parameter type, however do handle the `var_integer' variable type now, permitting existing parameters defined by GDB proper, such as `listsize', to be accessed from Scheme code. With these changes in place it should be trivial for a Scheme or Python programmer to expand the syntax of the `make-parameter' command and the `gdb.Parameter' class initializer to have arbitrary extra literals along with their internal representation supplied. Update the testsuite accordingly. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-19 21:15:56 +00:00
if (parmclass == param_enum)
{
if (! compute_enum_values (obj, enum_values))
return -1;
}
else
obj->enumeration = NULL;
GDB: Allow arbitrary keywords in integer set commands Rather than just `unlimited' allow the integer set commands (or command options) to define arbitrary keywords for the user to use, removing hardcoded arrangements for the `unlimited' keyword. Remove the confusingly named `var_zinteger', `var_zuinteger' and `var_zuinteger_unlimited' `set'/`show' command variable types redefining them in terms of `var_uinteger', `var_integer' and `var_pinteger', which have the range of [0;UINT_MAX], [INT_MIN;INT_MAX], and [0;INT_MAX] each. Following existing practice `var_pinteger' allows extra negative values to be used, however unlike `var_zuinteger_unlimited' any number of such values can be defined rather than just `-1'. The "p" in `var_pinteger' stands for "positive", for the lack of a more appropriate unambiguous letter, even though 0 obviously is not positive; "n" would be confusing as to whether it stands for "non-negative" or "negative". Add a new structure, `literal_def', the entries of which define extra keywords allowed for a command and numerical values they correspond to. Those values are not verified against the basic range supported by the underlying variable type, allowing extra values to be allowed outside that range, which may or may not be individually made visible to the user. An optional value translation is possible with the structure to follow the existing practice for some commands where user-entered 0 is internally translated to UINT_MAX or INT_MAX. Such translation can now be arbitrary. Literals defined by this structure are automatically used for completion as necessary. So for example: const literal_def integer_unlimited_literals[] = { { "unlimited", INT_MAX, 0 }, { nullptr } }; defines an extra `unlimited' keyword and a user-visible 0 value, both of which get translated to INT_MAX for the setting to be used with. Similarly: const literal_def zuinteger_unlimited_literals[] = { { "unlimited", -1, -1 }, { nullptr } }; defines the same keyword and a corresponding user-visible -1 value that is used for the requested setting. If the last member were omitted (or set to `{}') here, then only the keyword would be allowed for the user to enter and while -1 would still be used internally trying to enter it as a part of a command would result in an "integer -1 out of range" error. Use said error message in all cases (citing the invalid value requested) replacing "only -1 is allowed to set as unlimited" previously used for `var_zuinteger_unlimited' settings only rather than propagating it to `var_pinteger' type. It could only be used for the specific case where a single extra `unlimited' keyword was defined standing for -1 and the use of numeric equivalents is discouraged anyway as it is for historical reasons only that they expose GDB internals, confusingly different across variable types. Similarly update the "must be >= -1" Guile error message. Redefine Guile and Python parameter types in terms of the new variable types and interpret extra keywords as Scheme keywords and Python strings used to communicate corresponding parameter values. Do not add a new PARAM_INTEGER Guile parameter type, however do handle the `var_integer' variable type now, permitting existing parameters defined by GDB proper, such as `listsize', to be accessed from Scheme code. With these changes in place it should be trivial for a Scheme or Python programmer to expand the syntax of the `make-parameter' command and the `gdb.Parameter' class initializer to have arbitrary extra literals along with their internal representation supplied. Update the testsuite accordingly. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-19 21:15:56 +00:00
type = param_to_var[parmclass].type;
extra_literals = param_to_var[parmclass].extra_literals;
obj->type = type;
obj->extra_literals = extra_literals;
obj->value = {}; /* zeros initialization */
gdb: make string-like set show commands use std::string variable String-like settings (var_string, var_filename, var_optional_filename, var_string_noescape) currently take a pointer to a `char *` storage variable (typically global) that holds the setting's value. I'd like to "mordernize" this by changing them to use an std::string for storage. An obvious reason is that string operations on std::string are often easier to write than with C strings. And they avoid having to do any manual memory management. Another interesting reason is that, with `char *`, nullptr and an empty string often both have the same meaning of "no value". String settings are initially nullptr (unless initialized otherwise). But when doing "set foo" (where `foo` is a string setting), the setting now points to an empty string. For example, solib_search_path is nullptr at startup, but points to an empty string after doing "set solib-search-path". This leads to some code that needs to check for both to check for "no value". Or some code that converts back and forth between NULL and "" when getting or setting the value. I find this very error-prone, because it is very easy to forget one or the other. With std::string, we at least know that the variable is not "NULL". There is only one way of representing an empty string setting, that is with an empty string. I was wondering whether the distinction between NULL and "" would be important for some setting, but it doesn't seem so. If that ever happens, it would be more C++-y and self-descriptive to use optional<string> anyway. Actually, there's one spot where this distinction mattered, it's in init_history, for the test gdb.base/gdbinit-history.exp. init_history sets the history filename to the default ".gdb_history" if it sees that the setting was never set - if history_filename is nullptr. If history_filename is an empty string, it means the setting was explicitly cleared, so it leaves it as-is. With the change to std::string, this distinction doesn't exist anymore. This can be fixed by moving the code that chooses a good default value for history_filename to _initialize_top. This is ran before -ex commands are processed, so an -ex command can then clear that value if needed (what gdb.base/gdbinit-history.exp tests). Another small improvement, in my opinion is that we can now easily give string parameters initial values, by simply initializing the global variables, instead of xstrdup-ing it in the _initialize function. In Python and Guile, when registering a string-like parameter, we allocate (with new) an std::string that is owned by the param_smob (in Guile) and the parmpy_object (in Python) objects. This patch started by changing all relevant add_setshow_* commands to take an `std::string *` instead of a `char **` and fixing everything that failed to build. That includes of course all string setting variable and their uses. string_option_def now uses an std::string also, because there's a connection between options and settings (see add_setshow_cmds_for_options). The add_path function in source.c is really complex and twisted, I'd rather not try to change it to work on an std::string right now. Instead, I added an overload that copies the std:string to a `char *` and back. This means more copying, but this is not used in a hot path at all, so I think it is acceptable. Change-Id: I92c50a1bdd8307141cdbacb388248e4e4fc08c93 Co-authored-by: Lancelot SIX <lsix@lancelotsix.com>
2021-09-10 17:10:13 -04:00
if (var_type_uses<std::string> (obj->type))
obj->value.stringval = new std::string;
gdb::unique_xmalloc_ptr<char> cmd_name
= gdbpy_parse_command_name (name, &set_list, &setlist);
if (cmd_name == nullptr)
return -1;
cmd_name = gdbpy_parse_command_name (name, &show_list, &showlist);
if (cmd_name == nullptr)
return -1;
gdb/python: improve the auto help text for gdb.Parameter This commit attempts to improve the help text that is generated for gdb.Parameter objects when the user fails to provide their own documentation. Documentation for a gdb.Parameter is currently pulled from two sources: the class documentation string, and the set_doc/show_doc class attributes. Thus, a fully documented parameter might look like this: class Param_All (gdb.Parameter): """This is the class documentation string.""" show_doc = "Show the state of this parameter" set_doc = "Set the state of this parameter" def get_set_string (self): val = "on" if (self.value == False): val = "off" return "Test Parameter has been set to " + val def __init__ (self, name): super (Param_All, self).__init__ (name, gdb.COMMAND_DATA, gdb.PARAM_BOOLEAN) self._value = True Param_All ('param-all') Then in GDB we see this: (gdb) help set param-all Set the state of this parameter This is the class documentation string. Which is fine. But, if the user skips both of the documentation parts like this: class Param_None (gdb.Parameter): def get_set_string (self): val = "on" if (self.value == False): val = "off" return "Test Parameter has been set to " + val def __init__ (self, name): super (Param_None, self).__init__ (name, gdb.COMMAND_DATA, gdb.PARAM_BOOLEAN) self._value = True Param_None ('param-none') Now in GDB we see this: (gdb) help set param-none This command is not documented. This command is not documented. That's not great, the duplicated text looks a bit weird. If we drop different parts we get different results. Here's what we get if the user drops the set_doc and show_doc attributes: (gdb) help set param-doc This command is not documented. This is the class documentation string. That kind of sucks, we say it's undocumented, then proceed to print the documentation. Finally, if we drop the class documentation but keep the set_doc and show_doc: (gdb) help set param-set-show Set the state of this parameter This command is not documented. That seems OK. So, I think there's room for improvement. With this patch, for the four cases above we now see this: # All values provided by the user, no change in this case: (gdb) help set param-all Set the state of this parameter This is the class documentation string. # Nothing provided by the user, the first string is now different: (gdb) help set param-none Set the current value of 'param-none'. This command is not documented. # Only the class documentation is provided, the first string is # changed as in the previous case: (gdb) help set param-doc Set the current value of 'param-doc'. This is the class documentation string. # Only the set_doc and show_doc are provided, this case is unchanged # from before the patch: (gdb) help set param-set-show Set the state of this parameter This command is not documented. The one place where this change might be considered a negative is when dealing with prefix commands. If we create a prefix command but don't supply the set_doc / show_doc strings, then this is what we saw before my patch: (gdb) python Param_None ('print param-none') (gdb) help set print set print, set pr, set p Generic command for setting how things print. List of set print subcommands: ... snip ... set print param-none -- This command is not documented. ... snip ... And after my patch: (gdb) python Param_None ('print param-none') (gdb) help set print set print, set pr, set p Generic command for setting how things print. List of set print subcommands: ... snip ... set print param-none -- Set the current value of 'print param-none'. ... snip ... This seems slightly less helpful than before, but I don't think its terrible. Additionally, I've changed what we print when the get_show_string method is not provided in Python. Back when gdb.Parameter was first added to GDB, we didn't provide a show function when registering the internal command object within GDB. As a result, GDB would make use of its "magic" mangling of the show_doc string to create a sentence that would display the current value (see deprecated_show_value_hack in cli/cli-setshow.c). However, when we added support for the get_show_string method to gdb.Parameter, there was an attempt to maintain backward compatibility by displaying the show_doc string with the current value appended, see get_show_value in py-param.c. Unfortunately, this isn't anywhere close to what deprecated_show_value_hack does, and the results are pretty poor, for example, this is GDB before my patch: (gdb) show param-none This command is not documented. off I think we can all agree that this is pretty bad. After my patch, we how show this: (gdb) show param-none The current value of 'param-none' is "off". Which at least is a real sentence, even if it's not very informative. This patch does change the way that the Python API behaves slightly, but only in the cases when the user has missed providing GDB with some information. In most cases I think the new behaviour is a lot better, there's the one case (noted above) which is a bit iffy, but I think is still OK. I've updated the existing gdb.python/py-parameter.exp test to cover the modified behaviour. Finally, I've updated the documentation to (I hope) make it clearer how the various bits of help text come together.
2022-01-07 16:48:49 +00:00
set_doc = get_doc_string (self, doc_string_set, name);
show_doc = get_doc_string (self, doc_string_show, name);
doc = get_doc_string (self, doc_string_description, cmd_name.get ());
gdb/python: allow empty gdb.Parameter.__doc__ string I was recently attempting to create some parameters via the Python API. I wanted these parameters to appear similar to how GDB handles the existing 'style' parameters. Specifically, I was interested in this behaviour: (gdb) help show style filename foreground Show the foreground color for this property. (gdb) help set style filename foreground Set the foreground color for this property. (gdb) Notice how each 'help' command only gets a single line of output. I tried to reproduce this behaviour via the Python API and was unable. The problem is that, in order to get just a single line of output like this, the style parameters are registered with a call to add_setshow_color_cmd with the 'help_doc' being passed as nullptr. On the Python side, when parameters are created, the 'help_doc' is obtained with a call to get_doc_string (python/py-param.c). This function either returns the __doc__ string, or a default string: "This command is not documented.". To avoid returning the default we could try setting __doc__ to an empty string, but setting this field to any string means that GDB prints a line for that string, like this: class test_param(gdb.Parameter): __doc__ = "" def __init__(self, name): super ().__init__(name, gdb.COMMAND_NONE, gdb.PARAM_BOOLEAN) self.value = True test_param('print test') Then in GDB: (gdb) help set print test Set the current value of 'print test'. (gdb) The blank line is the problem I'd like to solve. This commit makes a couple of changes to how parameter doc strings are handled. If the doc string is set to an empty string, then GDB now converts this to nullptr, which removes the blank line problem, the new behaviour in GDB (for the above `test_param`) is: (gdb) help set print test Set the current value of 'print test'. (gdb) Next, I noticed that if the set/show docs are set to empty strings, then the results are less than ideal: class test_param(gdb.Parameter): set_doc = "" def __init__(self, name): super ().__init__(name, gdb.COMMAND_NONE, gdb.PARAM_BOOLEAN) self.value = True test_param('print test') And in GDB: (gdb) help set print test This command is not documented. (gdb) So, if the set/show docs are the empty string, GDB now forces these to be the default string instead, the new behaviour in GDB is: (gdb) help set print test Set the current value of 'print test'. This command is not documented. (gdb) I've added some additional asserts; the set/show docs should always be non-empty strings, which I believe is the case after this commit. And the 'doc' string returned from get_doc_string should never nullptr, but could be empty. There are new tests to cover all these changes.
2025-04-11 23:45:51 +01:00
/* The set/show docs should always be a non-empty string. */
gdb_assert (set_doc != nullptr && *set_doc != '\0');
gdb_assert (show_doc != nullptr && *show_doc != '\0');
/* For the DOC string only, if it is the empty string, then we convert it
to NULL. This means GDB will not even display a blank line for this
part of the help text, instead the set/show line is all the user will
get. */
gdb_assert (doc != nullptr);
if (*doc == '\0')
doc = nullptr;
Py_INCREF (self);
Rewrite TRY/CATCH This rewrites gdb's TRY/CATCH to plain C++ try/catch. The patch was largely written by script, though one change (to a comment in common-exceptions.h) was reverted by hand. gdb/ChangeLog 2019-04-08 Tom Tromey <tom@tromey.com> * xml-support.c: Use C++ exception handling. * x86-linux-nat.c: Use C++ exception handling. * windows-nat.c: Use C++ exception handling. * varobj.c: Use C++ exception handling. * value.c: Use C++ exception handling. * valprint.c: Use C++ exception handling. * valops.c: Use C++ exception handling. * unittests/parse-connection-spec-selftests.c: Use C++ exception handling. * unittests/cli-utils-selftests.c: Use C++ exception handling. * typeprint.c: Use C++ exception handling. * tui/tui.c: Use C++ exception handling. * tracefile-tfile.c: Use C++ exception handling. * top.c: Use C++ exception handling. * thread.c: Use C++ exception handling. * target.c: Use C++ exception handling. * symmisc.c: Use C++ exception handling. * symfile-mem.c: Use C++ exception handling. * stack.c: Use C++ exception handling. * sparc64-linux-tdep.c: Use C++ exception handling. * solib.c: Use C++ exception handling. * solib-svr4.c: Use C++ exception handling. * solib-spu.c: Use C++ exception handling. * solib-frv.c: Use C++ exception handling. * solib-dsbt.c: Use C++ exception handling. * selftest-arch.c: Use C++ exception handling. * s390-tdep.c: Use C++ exception handling. * rust-lang.c: Use C++ exception handling. * rust-exp.y: Use C++ exception handling. * rs6000-tdep.c: Use C++ exception handling. * rs6000-aix-tdep.c: Use C++ exception handling. * riscv-tdep.c: Use C++ exception handling. * remote.c: Use C++ exception handling. * remote-fileio.c: Use C++ exception handling. * record-full.c: Use C++ exception handling. * record-btrace.c: Use C++ exception handling. * python/python.c: Use C++ exception handling. * python/py-value.c: Use C++ exception handling. * python/py-utils.c: Use C++ exception handling. * python/py-unwind.c: Use C++ exception handling. * python/py-type.c: Use C++ exception handling. * python/py-symbol.c: Use C++ exception handling. * python/py-record.c: Use C++ exception handling. * python/py-record-btrace.c: Use C++ exception handling. * python/py-progspace.c: Use C++ exception handling. * python/py-prettyprint.c: Use C++ exception handling. * python/py-param.c: Use C++ exception handling. * python/py-objfile.c: Use C++ exception handling. * python/py-linetable.c: Use C++ exception handling. * python/py-lazy-string.c: Use C++ exception handling. * python/py-infthread.c: Use C++ exception handling. * python/py-inferior.c: Use C++ exception handling. * python/py-gdb-readline.c: Use C++ exception handling. * python/py-framefilter.c: Use C++ exception handling. * python/py-frame.c: Use C++ exception handling. * python/py-finishbreakpoint.c: Use C++ exception handling. * python/py-cmd.c: Use C++ exception handling. * python/py-breakpoint.c: Use C++ exception handling. * python/py-arch.c: Use C++ exception handling. * printcmd.c: Use C++ exception handling. * ppc-linux-tdep.c: Use C++ exception handling. * parse.c: Use C++ exception handling. * p-valprint.c: Use C++ exception handling. * objc-lang.c: Use C++ exception handling. * mi/mi-main.c: Use C++ exception handling. * mi/mi-interp.c: Use C++ exception handling. * mi/mi-cmd-stack.c: Use C++ exception handling. * mi/mi-cmd-break.c: Use C++ exception handling. * main.c: Use C++ exception handling. * linux-thread-db.c: Use C++ exception handling. * linux-tdep.c: Use C++ exception handling. * linux-nat.c: Use C++ exception handling. * linux-fork.c: Use C++ exception handling. * linespec.c: Use C++ exception handling. * language.c: Use C++ exception handling. * jit.c: Use C++ exception handling. * infrun.c: Use C++ exception handling. * infcmd.c: Use C++ exception handling. * infcall.c: Use C++ exception handling. * inf-loop.c: Use C++ exception handling. * i386-tdep.c: Use C++ exception handling. * i386-linux-tdep.c: Use C++ exception handling. * guile/scm-value.c: Use C++ exception handling. * guile/scm-type.c: Use C++ exception handling. * guile/scm-symtab.c: Use C++ exception handling. * guile/scm-symbol.c: Use C++ exception handling. * guile/scm-pretty-print.c: Use C++ exception handling. * guile/scm-ports.c: Use C++ exception handling. * guile/scm-param.c: Use C++ exception handling. * guile/scm-math.c: Use C++ exception handling. * guile/scm-lazy-string.c: Use C++ exception handling. * guile/scm-frame.c: Use C++ exception handling. * guile/scm-disasm.c: Use C++ exception handling. * guile/scm-cmd.c: Use C++ exception handling. * guile/scm-breakpoint.c: Use C++ exception handling. * guile/scm-block.c: Use C++ exception handling. * guile/guile-internal.h: Use C++ exception handling. * gnu-v3-abi.c: Use C++ exception handling. * gdbtypes.c: Use C++ exception handling. * frame.c: Use C++ exception handling. * frame-unwind.c: Use C++ exception handling. * fbsd-tdep.c: Use C++ exception handling. * f-valprint.c: Use C++ exception handling. * exec.c: Use C++ exception handling. * event-top.c: Use C++ exception handling. * event-loop.c: Use C++ exception handling. * eval.c: Use C++ exception handling. * dwarf2read.c: Use C++ exception handling. * dwarf2loc.c: Use C++ exception handling. * dwarf2-frame.c: Use C++ exception handling. * dwarf2-frame-tailcall.c: Use C++ exception handling. * dwarf-index-write.c: Use C++ exception handling. * dwarf-index-cache.c: Use C++ exception handling. * dtrace-probe.c: Use C++ exception handling. * disasm-selftests.c: Use C++ exception handling. * darwin-nat.c: Use C++ exception handling. * cp-valprint.c: Use C++ exception handling. * cp-support.c: Use C++ exception handling. * cp-abi.c: Use C++ exception handling. * corelow.c: Use C++ exception handling. * completer.c: Use C++ exception handling. * compile/compile-object-run.c: Use C++ exception handling. * compile/compile-object-load.c: Use C++ exception handling. * compile/compile-cplus-symbols.c: Use C++ exception handling. * compile/compile-c-symbols.c: Use C++ exception handling. * common/selftest.c: Use C++ exception handling. * common/new-op.c: Use C++ exception handling. * cli/cli-script.c: Use C++ exception handling. * cli/cli-interp.c: Use C++ exception handling. * cli/cli-cmds.c: Use C++ exception handling. * c-varobj.c: Use C++ exception handling. * btrace.c: Use C++ exception handling. * breakpoint.c: Use C++ exception handling. * break-catch-throw.c: Use C++ exception handling. * arch-utils.c: Use C++ exception handling. * amd64-tdep.c: Use C++ exception handling. * ada-valprint.c: Use C++ exception handling. * ada-typeprint.c: Use C++ exception handling. * ada-lang.c: Use C++ exception handling. * aarch64-tdep.c: Use C++ exception handling. gdb/gdbserver/ChangeLog 2019-04-08 Tom Tromey <tom@tromey.com> * server.c: Use C++ exception handling. * linux-low.c: Use C++ exception handling. * gdbreplay.c: Use C++ exception handling.
2019-04-03 16:02:42 -06:00
try
{
GDB: Allow arbitrary keywords in integer set commands Rather than just `unlimited' allow the integer set commands (or command options) to define arbitrary keywords for the user to use, removing hardcoded arrangements for the `unlimited' keyword. Remove the confusingly named `var_zinteger', `var_zuinteger' and `var_zuinteger_unlimited' `set'/`show' command variable types redefining them in terms of `var_uinteger', `var_integer' and `var_pinteger', which have the range of [0;UINT_MAX], [INT_MIN;INT_MAX], and [0;INT_MAX] each. Following existing practice `var_pinteger' allows extra negative values to be used, however unlike `var_zuinteger_unlimited' any number of such values can be defined rather than just `-1'. The "p" in `var_pinteger' stands for "positive", for the lack of a more appropriate unambiguous letter, even though 0 obviously is not positive; "n" would be confusing as to whether it stands for "non-negative" or "negative". Add a new structure, `literal_def', the entries of which define extra keywords allowed for a command and numerical values they correspond to. Those values are not verified against the basic range supported by the underlying variable type, allowing extra values to be allowed outside that range, which may or may not be individually made visible to the user. An optional value translation is possible with the structure to follow the existing practice for some commands where user-entered 0 is internally translated to UINT_MAX or INT_MAX. Such translation can now be arbitrary. Literals defined by this structure are automatically used for completion as necessary. So for example: const literal_def integer_unlimited_literals[] = { { "unlimited", INT_MAX, 0 }, { nullptr } }; defines an extra `unlimited' keyword and a user-visible 0 value, both of which get translated to INT_MAX for the setting to be used with. Similarly: const literal_def zuinteger_unlimited_literals[] = { { "unlimited", -1, -1 }, { nullptr } }; defines the same keyword and a corresponding user-visible -1 value that is used for the requested setting. If the last member were omitted (or set to `{}') here, then only the keyword would be allowed for the user to enter and while -1 would still be used internally trying to enter it as a part of a command would result in an "integer -1 out of range" error. Use said error message in all cases (citing the invalid value requested) replacing "only -1 is allowed to set as unlimited" previously used for `var_zuinteger_unlimited' settings only rather than propagating it to `var_pinteger' type. It could only be used for the specific case where a single extra `unlimited' keyword was defined standing for -1 and the use of numeric equivalents is discouraged anyway as it is for historical reasons only that they expose GDB internals, confusingly different across variable types. Similarly update the "must be >= -1" Guile error message. Redefine Guile and Python parameter types in terms of the new variable types and interpret extra keywords as Scheme keywords and Python strings used to communicate corresponding parameter values. Do not add a new PARAM_INTEGER Guile parameter type, however do handle the `var_integer' variable type now, permitting existing parameters defined by GDB proper, such as `listsize', to be accessed from Scheme code. With these changes in place it should be trivial for a Scheme or Python programmer to expand the syntax of the `make-parameter' command and the `gdb.Parameter' class initializer to have arbitrary extra literals along with their internal representation supplied. Update the testsuite accordingly. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-19 21:15:56 +00:00
add_setshow_generic (type, extra_literals,
(enum command_class) cmdtype,
std::move (cmd_name), obj,
set_doc.get (), show_doc.get (),
doc.get (), set_list, show_list);
}
Rename gdb exception types This renames the gdb exception types. The old types were only needed due to the macros in common-exception.h that are now gone. The intermediate layer of gdb_exception_RETURN_MASK_ALL did not seem needed, so this patch removes it entirely. gdb/ChangeLog 2019-04-08 Tom Tromey <tom@tromey.com> * common/common-exceptions.h (gdb_exception_RETURN_MASK_ALL): Remove. (gdb_exception_error): Rename from gdb_exception_RETURN_MASK_ERROR. (gdb_exception_quit): Rename from gdb_exception_RETURN_MASK_QUIT. (gdb_quit_bad_alloc): Update. * aarch64-tdep.c: Update. * ada-lang.c: Update. * ada-typeprint.c: Update. * ada-valprint.c: Update. * amd64-tdep.c: Update. * arch-utils.c: Update. * break-catch-throw.c: Update. * breakpoint.c: Update. * btrace.c: Update. * c-varobj.c: Update. * cli/cli-cmds.c: Update. * cli/cli-interp.c: Update. * cli/cli-script.c: Update. * common/common-exceptions.c: Update. * common/new-op.c: Update. * common/selftest.c: Update. * compile/compile-c-symbols.c: Update. * compile/compile-cplus-symbols.c: Update. * compile/compile-object-load.c: Update. * compile/compile-object-run.c: Update. * completer.c: Update. * corelow.c: Update. * cp-abi.c: Update. * cp-support.c: Update. * cp-valprint.c: Update. * darwin-nat.c: Update. * disasm-selftests.c: Update. * dtrace-probe.c: Update. * dwarf-index-cache.c: Update. * dwarf-index-write.c: Update. * dwarf2-frame-tailcall.c: Update. * dwarf2-frame.c: Update. * dwarf2loc.c: Update. * dwarf2read.c: Update. * eval.c: Update. * event-loop.c: Update. * event-top.c: Update. * exec.c: Update. * f-valprint.c: Update. * fbsd-tdep.c: Update. * frame-unwind.c: Update. * frame.c: Update. * gdbtypes.c: Update. * gnu-v3-abi.c: Update. * guile/guile-internal.h: Update. * guile/scm-block.c: Update. * guile/scm-breakpoint.c: Update. * guile/scm-cmd.c: Update. * guile/scm-disasm.c: Update. * guile/scm-frame.c: Update. * guile/scm-lazy-string.c: Update. * guile/scm-math.c: Update. * guile/scm-param.c: Update. * guile/scm-ports.c: Update. * guile/scm-pretty-print.c: Update. * guile/scm-symbol.c: Update. * guile/scm-symtab.c: Update. * guile/scm-type.c: Update. * guile/scm-value.c: Update. * i386-linux-tdep.c: Update. * i386-tdep.c: Update. * inf-loop.c: Update. * infcall.c: Update. * infcmd.c: Update. * infrun.c: Update. * jit.c: Update. * language.c: Update. * linespec.c: Update. * linux-fork.c: Update. * linux-nat.c: Update. * linux-tdep.c: Update. * linux-thread-db.c: Update. * main.c: Update. * mi/mi-cmd-break.c: Update. * mi/mi-cmd-stack.c: Update. * mi/mi-interp.c: Update. * mi/mi-main.c: Update. * objc-lang.c: Update. * p-valprint.c: Update. * parse.c: Update. * ppc-linux-tdep.c: Update. * printcmd.c: Update. * python/py-arch.c: Update. * python/py-breakpoint.c: Update. * python/py-cmd.c: Update. * python/py-finishbreakpoint.c: Update. * python/py-frame.c: Update. * python/py-framefilter.c: Update. * python/py-gdb-readline.c: Update. * python/py-inferior.c: Update. * python/py-infthread.c: Update. * python/py-lazy-string.c: Update. * python/py-linetable.c: Update. * python/py-objfile.c: Update. * python/py-param.c: Update. * python/py-prettyprint.c: Update. * python/py-progspace.c: Update. * python/py-record-btrace.c: Update. * python/py-record.c: Update. * python/py-symbol.c: Update. * python/py-type.c: Update. * python/py-unwind.c: Update. * python/py-utils.c: Update. * python/py-value.c: Update. * python/python.c: Update. * record-btrace.c: Update. * record-full.c: Update. * remote-fileio.c: Update. * remote.c: Update. * riscv-tdep.c: Update. * rs6000-aix-tdep.c: Update. * rs6000-tdep.c: Update. * rust-exp.y: Update. * rust-lang.c: Update. * s390-tdep.c: Update. * selftest-arch.c: Update. * solib-dsbt.c: Update. * solib-frv.c: Update. * solib-spu.c: Update. * solib-svr4.c: Update. * solib.c: Update. * sparc64-linux-tdep.c: Update. * stack.c: Update. * symfile-mem.c: Update. * symmisc.c: Update. * target.c: Update. * thread.c: Update. * top.c: Update. * tracefile-tfile.c: Update. * tui/tui.c: Update. * typeprint.c: Update. * unittests/cli-utils-selftests.c: Update. * unittests/parse-connection-spec-selftests.c: Update. * valops.c: Update. * valprint.c: Update. * value.c: Update. * varobj.c: Update. * windows-nat.c: Update. * x86-linux-nat.c: Update. * xml-support.c: Update. gdb/gdbserver/ChangeLog 2019-04-08 Tom Tromey <tom@tromey.com> * gdbreplay.c: Update. * linux-low.c: Update. * server.c: Update.
2019-04-03 15:59:07 -06:00
catch (const gdb_exception &except)
{
Py_DECREF (self);
return gdbpy_handle_gdb_exception (-1, except);
}
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
return 0;
}
gdb: make string-like set show commands use std::string variable String-like settings (var_string, var_filename, var_optional_filename, var_string_noescape) currently take a pointer to a `char *` storage variable (typically global) that holds the setting's value. I'd like to "mordernize" this by changing them to use an std::string for storage. An obvious reason is that string operations on std::string are often easier to write than with C strings. And they avoid having to do any manual memory management. Another interesting reason is that, with `char *`, nullptr and an empty string often both have the same meaning of "no value". String settings are initially nullptr (unless initialized otherwise). But when doing "set foo" (where `foo` is a string setting), the setting now points to an empty string. For example, solib_search_path is nullptr at startup, but points to an empty string after doing "set solib-search-path". This leads to some code that needs to check for both to check for "no value". Or some code that converts back and forth between NULL and "" when getting or setting the value. I find this very error-prone, because it is very easy to forget one or the other. With std::string, we at least know that the variable is not "NULL". There is only one way of representing an empty string setting, that is with an empty string. I was wondering whether the distinction between NULL and "" would be important for some setting, but it doesn't seem so. If that ever happens, it would be more C++-y and self-descriptive to use optional<string> anyway. Actually, there's one spot where this distinction mattered, it's in init_history, for the test gdb.base/gdbinit-history.exp. init_history sets the history filename to the default ".gdb_history" if it sees that the setting was never set - if history_filename is nullptr. If history_filename is an empty string, it means the setting was explicitly cleared, so it leaves it as-is. With the change to std::string, this distinction doesn't exist anymore. This can be fixed by moving the code that chooses a good default value for history_filename to _initialize_top. This is ran before -ex commands are processed, so an -ex command can then clear that value if needed (what gdb.base/gdbinit-history.exp tests). Another small improvement, in my opinion is that we can now easily give string parameters initial values, by simply initializing the global variables, instead of xstrdup-ing it in the _initialize function. In Python and Guile, when registering a string-like parameter, we allocate (with new) an std::string that is owned by the param_smob (in Guile) and the parmpy_object (in Python) objects. This patch started by changing all relevant add_setshow_* commands to take an `std::string *` instead of a `char **` and fixing everything that failed to build. That includes of course all string setting variable and their uses. string_option_def now uses an std::string also, because there's a connection between options and settings (see add_setshow_cmds_for_options). The add_path function in source.c is really complex and twisted, I'd rather not try to change it to work on an std::string right now. Instead, I added an overload that copies the std:string to a `char *` and back. This means more copying, but this is not used in a hot path at all, so I think it is acceptable. Change-Id: I92c50a1bdd8307141cdbacb388248e4e4fc08c93 Co-authored-by: Lancelot SIX <lsix@lancelotsix.com>
2021-09-10 17:10:13 -04:00
/* Deallocate function for a gdb.Parameter. */
static void
parmpy_dealloc (PyObject *obj)
{
parmpy_object *parm_obj = (parmpy_object *) obj;
if (var_type_uses<std::string> (parm_obj->type))
delete parm_obj->value.stringval;
else if (var_type_uses<ui_file_style::color> (parm_obj->type))
parm_obj->value.color.~color();
gdb: make string-like set show commands use std::string variable String-like settings (var_string, var_filename, var_optional_filename, var_string_noescape) currently take a pointer to a `char *` storage variable (typically global) that holds the setting's value. I'd like to "mordernize" this by changing them to use an std::string for storage. An obvious reason is that string operations on std::string are often easier to write than with C strings. And they avoid having to do any manual memory management. Another interesting reason is that, with `char *`, nullptr and an empty string often both have the same meaning of "no value". String settings are initially nullptr (unless initialized otherwise). But when doing "set foo" (where `foo` is a string setting), the setting now points to an empty string. For example, solib_search_path is nullptr at startup, but points to an empty string after doing "set solib-search-path". This leads to some code that needs to check for both to check for "no value". Or some code that converts back and forth between NULL and "" when getting or setting the value. I find this very error-prone, because it is very easy to forget one or the other. With std::string, we at least know that the variable is not "NULL". There is only one way of representing an empty string setting, that is with an empty string. I was wondering whether the distinction between NULL and "" would be important for some setting, but it doesn't seem so. If that ever happens, it would be more C++-y and self-descriptive to use optional<string> anyway. Actually, there's one spot where this distinction mattered, it's in init_history, for the test gdb.base/gdbinit-history.exp. init_history sets the history filename to the default ".gdb_history" if it sees that the setting was never set - if history_filename is nullptr. If history_filename is an empty string, it means the setting was explicitly cleared, so it leaves it as-is. With the change to std::string, this distinction doesn't exist anymore. This can be fixed by moving the code that chooses a good default value for history_filename to _initialize_top. This is ran before -ex commands are processed, so an -ex command can then clear that value if needed (what gdb.base/gdbinit-history.exp tests). Another small improvement, in my opinion is that we can now easily give string parameters initial values, by simply initializing the global variables, instead of xstrdup-ing it in the _initialize function. In Python and Guile, when registering a string-like parameter, we allocate (with new) an std::string that is owned by the param_smob (in Guile) and the parmpy_object (in Python) objects. This patch started by changing all relevant add_setshow_* commands to take an `std::string *` instead of a `char **` and fixing everything that failed to build. That includes of course all string setting variable and their uses. string_option_def now uses an std::string also, because there's a connection between options and settings (see add_setshow_cmds_for_options). The add_path function in source.c is really complex and twisted, I'd rather not try to change it to work on an std::string right now. Instead, I added an overload that copies the std:string to a `char *` and back. This means more copying, but this is not used in a hot path at all, so I think it is acceptable. Change-Id: I92c50a1bdd8307141cdbacb388248e4e4fc08c93 Co-authored-by: Lancelot SIX <lsix@lancelotsix.com>
2021-09-10 17:10:13 -04:00
}
/* Initialize the 'parameters' module. */
static int
gdbpy_initialize_parameters ()
{
int i;
parmpy_object_type.tp_new = PyType_GenericNew;
if (gdbpy_type_ready (&parmpy_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;
set_doc_cst = PyUnicode_FromString ("set_doc");
if (! set_doc_cst)
* 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;
show_doc_cst = PyUnicode_FromString ("show_doc");
if (! show_doc_cst)
* 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;
for (i = 0; parm_constants[i].name; ++i)
{
if (PyModule_AddIntConstant (gdb_module,
parm_constants[i].name,
parm_constants[i].value) < 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;
}
return 0;
}
gdb/python: add mechanism to manage Python initialization functions Currently, when we add a new python sub-system to GDB, e.g. py-inferior.c, we end up having to create a new function like gdbpy_initialize_inferior, which then has to be called from the function do_start_initialization in python.c. In some cases (py-micmd.c and py-tui.c), we have two functions gdbpy_initialize_*, and gdbpy_finalize_*, with the second being called from finalize_python which is also in python.c. This commit proposes a mechanism to manage these initialization and finalization calls, this means that adding a new Python subsystem will no longer require changes to python.c or python-internal.h, instead, the initialization and finalization functions will be registered directly from the sub-system file, e.g. py-inferior.c, or py-micmd.c. The initialization and finalization functions are managed through a new class gdbpy_initialize_file in python-internal.h. This class contains a single global vector of all the initialization and finalization functions. In each Python sub-system we create a new gdbpy_initialize_file object, the object constructor takes care of registering the two callback functions. Now from python.c we can call static functions on the gdbpy_initialize_file class which take care of walking the callback list and invoking each callback in turn. To slightly simplify the Python sub-system files I added a new macro GDBPY_INITIALIZE_FILE, which hides the need to create an object. We can now just do this: GDBPY_INITIALIZE_FILE (gdbpy_initialize_registers); One possible problem with this change is that there is now no guaranteed ordering of how the various sub-systems are initialized (or finalized). To try and avoid dependencies creeping in I have added a use of the environment variable GDB_REVERSE_INIT_FUNCTIONS, this is the same environment variable used in the generated init.c file. Just like with init.c, when this environment variable is set we reverse the list of Python initialization (and finalization) functions. As there is already a test that starts GDB with the environment variable set then this should offer some level of protection against dependencies creeping in - though for full protection I guess we'd need to run all gdb.python/*.exp tests with the variable set. I have tested this patch with the environment variable set, and saw no regressions, so I think we are fine right now. One other change of note was for gdbpy_initialize_gdb_readline, this function previously returned void. In order to make this function have the correct signature I've updated its return type to int, and we now return 0 to indicate success. All of the other initialize (and finalize) functions have been made static within their respective sub-system files. There should be no user visible changes after this commit.
2022-09-16 16:08:17 +01:00
GDBPY_INITIALIZE_FILE (gdbpy_initialize_parameters);
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 parmpy_object_type =
{
Add support for Python 3. * NEWS: Mention Python 3 support. * varobj.c (value_get_print_value): Use python_string_to_target_string. * python/py-block.c: Use PyVarObject_HEAD_INIT in initialization of type objects. * python/py-breakpoint.c: Ditto. * python/py-cmd.c: Ditto. * python/py-event.c: Ditto. * python/py-event.h: Ditto. * python/py-evtregistry.c: Ditto. * python/py-finishbreakpoint.c: Ditto. * python/py-frame.c: Ditto. * python/py-function.c: Ditto. * python/py-infthread.c: Ditto. * python/py-lazy-string.c: Ditto. * python/py-progspace.c: Ditto. * /python/py-symbol.c: Ditto. * python/py-evts.c: (gdbpy_initialize_py_events): Add module initialization for Python 3. * python/py-inferior.c: Use PyVarObject_HEAD_INIT in initialization of type objects. (infpy_read_memory): Return memoryview object if Python 3. (infpy_write_memory): Use "s*" operand parsing code for Python 3. (infpy_search_memory): Ditto. (get_buffer): New function for Python 3. * python/py-objfile.c: Use PyVarObject_HEAD_INIT in initialization of type objects. (objfpy_dealloc): Use Py_TYPE to call tp_free. * python/py-param.c: Use PyVarObject_HEAD_INIT in initialization of type objects. (get_attr): Use PyUnicode_CompareWithASCIIString if Python 3. (set_attr): Ditto. * python/py-prettyprint.c (print_string_repr): use PyBytes methods instead of PyString methods if Python 3. (print_children): Skip push_dummy_python_frame call if Python 3. * python/py-symtab.c: Use PyVarObject_HEAD_INIT in initialization of type objects. (salpy_dealloc): Use Py_TYPE to call tp_free. * python/py-type.c: Use PyVarObject_HEAD_INIT in initialization of type objects. (field_dealloc): Use Py_TYPE to call tp_free. (typy_dealloc): Ditto. (type_object_as_number): Adjust struct initializations for differences in layout for Python 2 vs. Python 3. * python/py-utils.c (python_string_to_unicode): Omit non-Unicode string case for Python 3. (unicode_to_encoded_python_string): Shorten code (no functional change). (python_string_to_target_python_string): Comment that in Python 3 returned value is a Python "bytes" type. (gdbpy_is_string): Omit non-Unicode string check in Python 3. (gdb_py_object_from_longest): Omit non-long integer case in Python 3. (gdb_py_object_from_ulongest): Ditto. * python/py-value.c: Use PyVarObject_HEAD_INIT in initialization of type objects. (valpy_dealloc): Use Py_TYPE to call tp_free. (valpy_int): Omit function if Python 3. (convert_value_from_python): Use "%S" format (Python object as a string) if Python 3. (value_object_as_number): Adjust struct initializations for differences in layout for Python 2 vs. Python 3. * python/python-config.py: Adjust syntax for Python 3 compatibility. Include "sys.abiflags" string as part of python library name, if that attribute exists (Python 3). * python/python-internal.h (IS_PY3): Define if Python 3. (Py_TPFLAGS_HAVE_ITER, Py_TPFLAGS_CHECKTYPES): Define with placeholder value if Python 3. (PyInt_Check, PyInt_FromLong, PyInt_AsLong, PyString_FromString, PyString_Decode, PyString_FromFormat, PyString_Check): Define as analogous Python 3 API function if Python 3. (PyVarObject_HEAD_INIT): Define if not already defined. (Py_TYPE): Ditto. * python/python.c (eval_python_command): Omit Py_FlushLine call if Python 3. Check return values of all Python API calls for error. Supply dummy "python" and "python-interactive" commands if Python initialization failed. (_initialize_python): Convert argc to wchar_t** if Python 3. Add module initialization for Python 3. (finish_python_initialization): Pass wchar_t * argument to PySys_SetPath if Python 3. * python/lib/gdb/__init__.py: Define "reload" if Python 3. (_GdbFile): New class for common output file behavior. (GdbOutFile): Subclass from _GdbFile. (GdbOutputErrorFile): Ditto. (auto_load_packages): Adjust syntax for Python 3 compatibility. * python/lib/gdb/printing.py: Define basestr and int if Python 3. * python/lib/gdb/prompt.py: Use sorted() function rather than sort() method. * python/lib/gdb/command/explore.py: Define raw_input if Python 3. Adjust syntax for Python 3 compatibility. * python/lib/gdb/command/pretty_printers.py: Use sorted() function rather than sort() method. Adjust syntax for Python 3 compatibility. * python/lib/gdb/command/type_printers.py: Ditto. * doc/gdb.texinfo (Inferior.read_memory): Mention that the return value is a memoryview object if Python 3.
2012-12-12 16:47:30 +00:00
PyVarObject_HEAD_INIT (NULL, 0)
"gdb.Parameter", /*tp_name*/
sizeof (parmpy_object), /*tp_basicsize*/
0, /*tp_itemsize*/
gdb: make string-like set show commands use std::string variable String-like settings (var_string, var_filename, var_optional_filename, var_string_noescape) currently take a pointer to a `char *` storage variable (typically global) that holds the setting's value. I'd like to "mordernize" this by changing them to use an std::string for storage. An obvious reason is that string operations on std::string are often easier to write than with C strings. And they avoid having to do any manual memory management. Another interesting reason is that, with `char *`, nullptr and an empty string often both have the same meaning of "no value". String settings are initially nullptr (unless initialized otherwise). But when doing "set foo" (where `foo` is a string setting), the setting now points to an empty string. For example, solib_search_path is nullptr at startup, but points to an empty string after doing "set solib-search-path". This leads to some code that needs to check for both to check for "no value". Or some code that converts back and forth between NULL and "" when getting or setting the value. I find this very error-prone, because it is very easy to forget one or the other. With std::string, we at least know that the variable is not "NULL". There is only one way of representing an empty string setting, that is with an empty string. I was wondering whether the distinction between NULL and "" would be important for some setting, but it doesn't seem so. If that ever happens, it would be more C++-y and self-descriptive to use optional<string> anyway. Actually, there's one spot where this distinction mattered, it's in init_history, for the test gdb.base/gdbinit-history.exp. init_history sets the history filename to the default ".gdb_history" if it sees that the setting was never set - if history_filename is nullptr. If history_filename is an empty string, it means the setting was explicitly cleared, so it leaves it as-is. With the change to std::string, this distinction doesn't exist anymore. This can be fixed by moving the code that chooses a good default value for history_filename to _initialize_top. This is ran before -ex commands are processed, so an -ex command can then clear that value if needed (what gdb.base/gdbinit-history.exp tests). Another small improvement, in my opinion is that we can now easily give string parameters initial values, by simply initializing the global variables, instead of xstrdup-ing it in the _initialize function. In Python and Guile, when registering a string-like parameter, we allocate (with new) an std::string that is owned by the param_smob (in Guile) and the parmpy_object (in Python) objects. This patch started by changing all relevant add_setshow_* commands to take an `std::string *` instead of a `char **` and fixing everything that failed to build. That includes of course all string setting variable and their uses. string_option_def now uses an std::string also, because there's a connection between options and settings (see add_setshow_cmds_for_options). The add_path function in source.c is really complex and twisted, I'd rather not try to change it to work on an std::string right now. Instead, I added an overload that copies the std:string to a `char *` and back. This means more copying, but this is not used in a hot path at all, so I think it is acceptable. Change-Id: I92c50a1bdd8307141cdbacb388248e4e4fc08c93 Co-authored-by: Lancelot SIX <lsix@lancelotsix.com>
2021-09-10 17:10:13 -04:00
parmpy_dealloc, /*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*/
get_attr, /*tp_getattro*/
set_attr, /*tp_setattro*/
0, /*tp_as_buffer*/
Py_TPFLAGS_DEFAULT | Py_TPFLAGS_BASETYPE, /*tp_flags*/
"GDB parameter object", /* tp_doc */
0, /* tp_traverse */
0, /* tp_clear */
0, /* tp_richcompare */
0, /* tp_weaklistoffset */
0, /* tp_iter */
0, /* tp_iternext */
0, /* 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 */
parmpy_init, /* tp_init */
0, /* tp_alloc */
};