2010-04-29 15:45:57 +00:00
|
|
|
|
/* GDB parameters implemented in Python
|
|
|
|
|
|
|
2026-01-05 08:13:29 -07:00
|
|
|
|
Copyright (C) 2008-2026 Free Software Foundation, Inc.
|
2010-04-29 15:45:57 +00:00
|
|
|
|
|
|
|
|
|
|
This file is part of GDB.
|
|
|
|
|
|
|
|
|
|
|
|
This program is free software; you can redistribute it and/or modify
|
|
|
|
|
|
it under the terms of the GNU General Public License as published by
|
|
|
|
|
|
the Free Software Foundation; either version 3 of the License, or
|
|
|
|
|
|
(at your option) any later version.
|
|
|
|
|
|
|
|
|
|
|
|
This program is distributed in the hope that it will be useful,
|
|
|
|
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
|
GNU General Public License for more details.
|
|
|
|
|
|
|
|
|
|
|
|
You should have received a copy of the GNU General Public License
|
|
|
|
|
|
along with this program. If not, see <http://www.gnu.org/licenses/>. */
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#include "value.h"
|
|
|
|
|
|
#include "python-internal.h"
|
|
|
|
|
|
#include "charset.h"
|
2024-04-23 15:22:44 -04:00
|
|
|
|
#include "cli/cli-cmds.h"
|
2010-04-29 15:45:57 +00:00
|
|
|
|
#include "cli/cli-decode.h"
|
|
|
|
|
|
#include "completer.h"
|
2011-03-10 12:29:08 +00:00
|
|
|
|
#include "language.h"
|
|
|
|
|
|
#include "arch-utils.h"
|
2024-10-05 22:27:44 +03:00
|
|
|
|
#include "py-color.h"
|
2010-04-29 15:45:57 +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
|
|
|
|
/* Python parameter types as in PARM_CONSTANTS below. */
|
|
|
|
|
|
|
2023-08-14 18:32:29 +02:00
|
|
|
|
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,
|
2024-10-05 22:27:44 +03:00
|
|
|
|
param_color,
|
2023-08-14 18:32:29 +02: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
|
|
|
|
|
|
|
|
|
|
/* 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 },
|
2024-10-05 22:27:44 +03:00
|
|
|
|
{ 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
|
|
|
|
};
|
|
|
|
|
|
|
2010-04-29 15:45:57 +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;
|
2010-04-29 15:45:57 +00:00
|
|
|
|
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[] =
|
2010-04-29 15:45:57 +00:00
|
|
|
|
{
|
2026-06-18 10:00:20 -06:00
|
|
|
|
{ "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 },
|
2024-10-05 22:27:44 +03:00
|
|
|
|
{ "PARAM_COLOR", param_color },
|
2010-04-29 15:45:57 +00:00
|
|
|
|
{ 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. */
|
2010-04-29 15:45:57 +00:00
|
|
|
|
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;
|
2010-04-29 15:45:57 +00:00
|
|
|
|
|
|
|
|
|
|
/* Hold a string, for enums. */
|
|
|
|
|
|
const char *cstringval;
|
2024-10-05 22:27:44 +03:00
|
|
|
|
|
|
|
|
|
|
/* Hold a color. */
|
|
|
|
|
|
ui_file_style::color color;
|
2010-04-29 15:45:57 +00:00
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
/* A GDB parameter. */
|
2026-01-27 12:33:42 +00:00
|
|
|
|
struct parmpy_object : public PyObject
|
2010-04-29 15:45:57 +00:00
|
|
|
|
{
|
|
|
|
|
|
/* 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;
|
|
|
|
|
|
|
2010-04-29 15:45:57 +00:00
|
|
|
|
/* 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);
|
2024-10-05 22:27:44 +03:00
|
|
|
|
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");
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2025-10-21 10:00:20 -06:00
|
|
|
|
extern PyTypeObject parmpy_object_type;
|
2010-04-29 15:45:57 +00:00
|
|
|
|
|
|
|
|
|
|
/* 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)
|
|
|
|
|
|
{
|
2022-03-21 10:07:41 -04:00
|
|
|
|
if (PyUnicode_Check (attr_name)
|
2012-12-12 16:47:30 +00:00
|
|
|
|
&& ! PyUnicode_CompareWithASCIIString (attr_name, "value"))
|
2010-04-29 15:45:57 +00:00
|
|
|
|
{
|
|
|
|
|
|
parmpy_object *self = (parmpy_object *) obj;
|
2010-05-17 21:23:25 +00:00
|
|
|
|
|
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));
|
2010-04-29 15:45:57 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
return PyObject_GenericGetAttr (obj, attr_name);
|
|
|
|
|
|
}
|
|
|
|
|
|
|
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. */
|
2010-04-29 15:45:57 +00:00
|
|
|
|
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))
|
|
|
|
|
|
{
|
2013-11-29 12:00:47 -08:00
|
|
|
|
PyErr_SetString (PyExc_RuntimeError,
|
2010-04-29 15:45:57 +00:00
|
|
|
|
_("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 ();
|
2010-04-29 15:45:57 +00:00
|
|
|
|
else
|
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));
|
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 ();
|
2010-10-13 13:24:40 +00:00
|
|
|
|
}
|
2010-04-29 15:45:57 +00:00
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
|
|
case var_enum:
|
|
|
|
|
|
{
|
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
|
|
if (! gdbpy_is_string (value))
|
|
|
|
|
|
{
|
2013-11-29 12:00:47 -08:00
|
|
|
|
PyErr_SetString (PyExc_RuntimeError,
|
2010-04-29 15:45:57 +00:00
|
|
|
|
_("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));
|
2010-10-13 13:24:40 +00:00
|
|
|
|
if (str == NULL)
|
|
|
|
|
|
return -1;
|
2010-04-29 15:45:57 +00:00
|
|
|
|
for (i = 0; self->enumeration[i]; ++i)
|
2026-03-16 11:23:19 -04:00
|
|
|
|
if (streq (self->enumeration[i], str.get ()))
|
2010-04-29 15:45:57 +00:00
|
|
|
|
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;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2024-10-05 22:27:44 +03:00
|
|
|
|
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;
|
|
|
|
|
|
|
2010-04-29 15:45:57 +00:00
|
|
|
|
case var_boolean:
|
|
|
|
|
|
if (! PyBool_Check (value))
|
|
|
|
|
|
{
|
2013-11-29 12:00:47 -08:00
|
|
|
|
PyErr_SetString (PyExc_RuntimeError,
|
2010-04-29 15:45:57 +00:00
|
|
|
|
_("A boolean argument is required."));
|
|
|
|
|
|
return -1;
|
|
|
|
|
|
}
|
|
|
|
|
|
cmp = PyObject_IsTrue (value);
|
2013-11-29 12:00:47 -08:00
|
|
|
|
if (cmp < 0)
|
2010-04-29 15:45:57 +00:00
|
|
|
|
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;
|
2010-04-29 15:45:57 +00:00
|
|
|
|
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 )
|
2025-10-10 23:59:32 -04:00
|
|
|
|
return -1;
|
2010-04-29 15:45:57 +00:00
|
|
|
|
if (cmp == 1)
|
|
|
|
|
|
self->value.autoboolval = AUTO_BOOLEAN_TRUE;
|
2013-11-29 12:00:47 -08:00
|
|
|
|
else
|
2010-04-29 15:45:57 +00:00
|
|
|
|
self->value.autoboolval = AUTO_BOOLEAN_FALSE;
|
|
|
|
|
|
}
|
2011-02-28 18:28:19 +00:00
|
|
|
|
break;
|
2010-04-29 15:45:57 +00:00
|
|
|
|
|
|
|
|
|
|
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:
|
2010-04-29 15:45:57 +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
|
|
|
|
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)
|
2010-04-29 15:45:57 +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
|
|
|
|
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
|
2026-03-16 11:23:19 -04:00
|
|
|
|
&& ((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;
|
|
|
|
|
|
}
|
|
|
|
|
|
}
|
2010-04-29 15:45:57 +00:00
|
|
|
|
}
|
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)
|
2010-04-29 15:45:57 +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
|
|
|
|
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;
|
2010-04-29 15:45:57 +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_FALSE)
|
2010-04-29 15:45:57 +00:00
|
|
|
|
{
|
2013-11-29 12:00:47 -08:00
|
|
|
|
PyErr_SetString (PyExc_RuntimeError,
|
2010-04-29 15:45:57 +00:00
|
|
|
|
_("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;
|
2018-04-26 16:18:07 -06:00
|
|
|
|
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;
|
2010-04-29 15:45:57 +00:00
|
|
|
|
break;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
default:
|
2013-11-29 12:00:47 -08:00
|
|
|
|
PyErr_SetString (PyExc_RuntimeError,
|
2010-04-29 15:45:57 +00:00
|
|
|
|
_("Unhandled type in parameter value."));
|
|
|
|
|
|
return -1;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2010-10-13 13:24:40 +00:00
|
|
|
|
/* Set an attribute. Returns -1 on error, with a python exception set. */
|
2010-04-29 15:45:57 +00:00
|
|
|
|
static int
|
|
|
|
|
|
set_attr (PyObject *obj, PyObject *attr_name, PyObject *val)
|
|
|
|
|
|
{
|
2022-03-21 10:07:41 -04:00
|
|
|
|
if (PyUnicode_Check (attr_name)
|
2012-12-12 16:47:30 +00:00
|
|
|
|
&& ! PyUnicode_CompareWithASCIIString (attr_name, "value"))
|
2010-04-29 15:45:57 +00:00
|
|
|
|
{
|
|
|
|
|
|
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
|
|
|
|
|
|
};
|
|
|
|
|
|
|
2011-03-10 12:29:08 +00:00
|
|
|
|
/* 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)
|
2011-03-10 12:29:08 +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> result;
|
2011-03-10 12:29:08 +00:00
|
|
|
|
|
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);
|
|
|
|
|
|
|
2011-03-10 12:29:08 +00:00
|
|
|
|
if (PyObject_HasAttr (object, attr))
|
|
|
|
|
|
{
|
Turn gdbpy_ref into a template
This turns gdbpy_ref into a template class, so that it can be used to
wrap subclasses of PyObject. The default argument remains PyObject;
and this necessitated renaming uses of "gdbpy_ref" to "gdbpy_ref<>".
gdb/ChangeLog
2017-02-10 Tom Tromey <tom@tromey.com>
* python/py-ref.h (gdbpy_ref_policy): Now a template.
(gdbpy_ref): Now a template; allow subclasses of PyObject to be
used.
* python/py-arch.c, python/py-bpevent.c, python/py-breakpoint.c,
python/py-cmd.c, python/py-continueevent.c, python/py-event.c,
python/py-exitedevent.c, python/py-finishbreakpoint.c,
python/py-framefilter.c, python/py-function.c,
python/py-inferior.c, python/py-infevents.c,
python/py-linetable.c, python/py-newobjfileevent.c,
python/py-param.c, python/py-prettyprint.c, python/py-ref.h,
python/py-signalevent.c, python/py-stopevent.c,
python/py-symbol.c, python/py-threadevent.c, python/py-type.c,
python/py-unwind.c, python/py-utils.c, python/py-value.c,
python/py-varobj.c, python/py-xmethods.c, python/python.c,
varobj.c: Change gdbpy_ref to gdbpy_ref<>.
2017-02-09 13:16:36 -07:00
|
|
|
|
gdbpy_ref<> ds_obj (PyObject_GetAttr (object, attr));
|
2011-03-10 12:29:08 +00:00
|
|
|
|
|
2016-11-20 10:34:34 -07:00
|
|
|
|
if (ds_obj != NULL && gdbpy_is_string (ds_obj.get ()))
|
2011-03-10 12:29:08 +00:00
|
|
|
|
{
|
2016-11-20 10:34:34 -07:00
|
|
|
|
result = python_string_to_host_string (ds_obj.get ());
|
2011-03-10 12:29:08 +00:00
|
|
|
|
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));
|
2011-03-10 12:29:08 +00:00
|
|
|
|
}
|
|
|
|
|
|
}
|
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)
|
2026-01-15 08:27:58 -07:00
|
|
|
|
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);
|
|
|
|
|
|
}
|
|
|
|
|
|
}
|
2011-03-10 12:29:08 +00:00
|
|
|
|
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>
|
2011-03-10 12:29:08 +00:00
|
|
|
|
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;
|
Turn gdbpy_ref into a template
This turns gdbpy_ref into a template class, so that it can be used to
wrap subclasses of PyObject. The default argument remains PyObject;
and this necessitated renaming uses of "gdbpy_ref" to "gdbpy_ref<>".
gdb/ChangeLog
2017-02-10 Tom Tromey <tom@tromey.com>
* python/py-ref.h (gdbpy_ref_policy): Now a template.
(gdbpy_ref): Now a template; allow subclasses of PyObject to be
used.
* python/py-arch.c, python/py-bpevent.c, python/py-breakpoint.c,
python/py-cmd.c, python/py-continueevent.c, python/py-event.c,
python/py-exitedevent.c, python/py-finishbreakpoint.c,
python/py-framefilter.c, python/py-function.c,
python/py-inferior.c, python/py-infevents.c,
python/py-linetable.c, python/py-newobjfileevent.c,
python/py-param.c, python/py-prettyprint.c, python/py-ref.h,
python/py-signalevent.c, python/py-stopevent.c,
python/py-symbol.c, python/py-threadevent.c, python/py-type.c,
python/py-unwind.c, python/py-utils.c, python/py-value.c,
python/py-varobj.c, python/py-xmethods.c, python/python.c,
varobj.c: Change gdbpy_ref to gdbpy_ref<>.
2017-02-09 13:16:36 -07:00
|
|
|
|
gdbpy_ref<> result (PyObject_CallMethodObjArgs (obj, method, arg, NULL));
|
2011-03-10 12:29:08 +00:00
|
|
|
|
|
2016-11-06 21:29:12 -07:00
|
|
|
|
if (result == NULL)
|
2011-03-10 12:29:08 +00:00
|
|
|
|
return NULL;
|
|
|
|
|
|
|
2016-11-06 21:29:12 -07:00
|
|
|
|
if (gdbpy_is_string (result.get ()))
|
2011-03-10 12:29:08 +00:00
|
|
|
|
{
|
2016-11-06 21:29:12 -07:00
|
|
|
|
data = python_string_to_host_string (result.get ());
|
2011-03-10 12:29:08 +00:00
|
|
|
|
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
|
2021-03-18 16:44:14 +00:00
|
|
|
|
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. */
|
2011-03-10 12:29:08 +00:00
|
|
|
|
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,
|
2011-03-10 12:29:08 +00:00
|
|
|
|
struct cmd_list_element *c)
|
|
|
|
|
|
{
|
2021-06-25 21:35:40 -04:00
|
|
|
|
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;
|
2011-03-10 12:29:08 +00:00
|
|
|
|
|
Change how Python architecture and language are handled
Currently, gdb's Python layer captures the current architecture and
language when "entering" Python code. This has some undesirable
effects, and so this series changes how this is handled.
First, there is code like this:
gdbpy_enter enter_py (python_gdbarch, python_language);
This is incorrect, because both of these are NULL when not otherwise
assigned. This can cause crashes in some cases -- I've added one to
the test suite. (Note that this crasher is just an example, other
ones along the same lines are possible.)
Second, when the language is captured in this way, it means that
Python code cannot affect the current language for its own purposes.
It's reasonable to want to write code like this:
gdb.execute('set language mumble')
... stuff using the current language
gdb.execute('set language previous-value')
However, this won't actually work, because the language is captured on
entry. I've added a test to show this as well.
This patch changes gdb to try to avoid capturing the current values.
The Python concept of the current gdbarch is only set in those few
cases where a non-default value is computed or needed; and the
language is not captured at all -- instead, in the cases where it's
required, the current language is temporarily changed.
2022-01-04 08:02:24 -07:00
|
|
|
|
gdbpy_enter enter_py;
|
2022-03-21 10:07:41 -04:00
|
|
|
|
gdbpy_ref<> set_doc_func (PyUnicode_FromString ("get_set_string"));
|
2011-03-10 12:29:08 +00:00
|
|
|
|
|
2016-11-12 11:23:36 -07:00
|
|
|
|
if (set_doc_func == NULL)
|
2011-03-10 12:29:08 +00:00
|
|
|
|
{
|
2016-11-12 11:23:36 -07:00
|
|
|
|
gdbpy_print_stack ();
|
|
|
|
|
|
return;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
if (PyObject_HasAttr (obj, set_doc_func.get ()))
|
|
|
|
|
|
{
|
|
|
|
|
|
set_doc_string = call_doc_function (obj, set_doc_func.get (), NULL);
|
2011-03-10 12:29:08 +00:00
|
|
|
|
if (! set_doc_string)
|
2018-09-15 01:09:22 -06:00
|
|
|
|
gdbpy_handle_exception ();
|
2011-03-10 12:29:08 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
2018-04-26 16:51:40 -06:00
|
|
|
|
const char *str = set_doc_string.get ();
|
|
|
|
|
|
if (str != nullptr && str[0] != '\0')
|
2022-01-02 11:46:15 -07:00
|
|
|
|
gdb_printf ("%s\n", str);
|
2011-03-10 12:29:08 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* 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)
|
|
|
|
|
|
{
|
2021-06-25 21:35:40 -04:00
|
|
|
|
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;
|
2011-03-10 12:29:08 +00:00
|
|
|
|
|
Change how Python architecture and language are handled
Currently, gdb's Python layer captures the current architecture and
language when "entering" Python code. This has some undesirable
effects, and so this series changes how this is handled.
First, there is code like this:
gdbpy_enter enter_py (python_gdbarch, python_language);
This is incorrect, because both of these are NULL when not otherwise
assigned. This can cause crashes in some cases -- I've added one to
the test suite. (Note that this crasher is just an example, other
ones along the same lines are possible.)
Second, when the language is captured in this way, it means that
Python code cannot affect the current language for its own purposes.
It's reasonable to want to write code like this:
gdb.execute('set language mumble')
... stuff using the current language
gdb.execute('set language previous-value')
However, this won't actually work, because the language is captured on
entry. I've added a test to show this as well.
This patch changes gdb to try to avoid capturing the current values.
The Python concept of the current gdbarch is only set in those few
cases where a non-default value is computed or needed; and the
language is not captured at all -- instead, in the cases where it's
required, the current language is temporarily changed.
2022-01-04 08:02:24 -07:00
|
|
|
|
gdbpy_enter enter_py;
|
2022-03-21 10:07:41 -04:00
|
|
|
|
gdbpy_ref<> show_doc_func (PyUnicode_FromString ("get_show_string"));
|
2016-11-12 11:23:36 -07:00
|
|
|
|
|
|
|
|
|
|
if (show_doc_func == NULL)
|
|
|
|
|
|
{
|
|
|
|
|
|
gdbpy_print_stack ();
|
|
|
|
|
|
return;
|
|
|
|
|
|
}
|
2011-03-10 12:29:08 +00:00
|
|
|
|
|
2016-11-12 11:23:36 -07:00
|
|
|
|
if (PyObject_HasAttr (obj, show_doc_func.get ()))
|
2011-03-10 12:29:08 +00:00
|
|
|
|
{
|
2022-03-21 10:07:41 -04:00
|
|
|
|
gdbpy_ref<> val_obj (PyUnicode_FromString (value));
|
2011-03-10 12:29:08 +00:00
|
|
|
|
|
2016-11-12 11:23:36 -07:00
|
|
|
|
if (val_obj == NULL)
|
|
|
|
|
|
{
|
|
|
|
|
|
gdbpy_print_stack ();
|
|
|
|
|
|
return;
|
|
|
|
|
|
}
|
2011-03-10 12:29:08 +00:00
|
|
|
|
|
2016-11-12 11:23:36 -07:00
|
|
|
|
show_doc_string = call_doc_function (obj, show_doc_func.get (),
|
|
|
|
|
|
val_obj.get ());
|
2011-03-10 12:29:08 +00:00
|
|
|
|
if (! show_doc_string)
|
2016-11-12 11:23:36 -07:00
|
|
|
|
{
|
|
|
|
|
|
gdbpy_print_stack ();
|
|
|
|
|
|
return;
|
|
|
|
|
|
}
|
2011-03-10 12:29:08 +00:00
|
|
|
|
|
2022-01-02 11:46:15 -07:00
|
|
|
|
gdb_printf (file, "%s\n", show_doc_string.get ());
|
2011-03-10 12:29:08 +00:00
|
|
|
|
}
|
|
|
|
|
|
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);
|
2022-01-02 11:46:15 -07:00
|
|
|
|
gdb_printf (file, _("The current value of '%s' is \"%s\".\n"),
|
|
|
|
|
|
cmd_path.c_str (), value);
|
2011-03-10 12:29:08 +00:00
|
|
|
|
}
|
|
|
|
|
|
}
|
2010-04-29 15:45:57 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* 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,
|
2021-05-12 13:50:05 -04:00
|
|
|
|
gdb::unique_xmalloc_ptr<char> cmd_name,
|
|
|
|
|
|
parmpy_object *self,
|
2018-06-20 15:35:04 -06:00
|
|
|
|
const char *set_doc, const char *show_doc,
|
|
|
|
|
|
const char *help_doc,
|
2010-04-29 15:45:57 +00:00
|
|
|
|
struct cmd_list_element **set_list,
|
|
|
|
|
|
struct cmd_list_element **show_list)
|
|
|
|
|
|
{
|
2021-05-27 13:59:00 -04:00
|
|
|
|
set_show_commands commands;
|
2011-03-10 12:29:08 +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
|
|
|
|
switch (type)
|
2010-04-29 15:45:57 +00:00
|
|
|
|
{
|
|
|
|
|
|
case var_boolean:
|
2021-05-27 13:59:00 -04:00
|
|
|
|
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);
|
2011-03-10 12:29:08 +00:00
|
|
|
|
|
2010-04-29 15:45:57 +00:00
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
|
|
case var_auto_boolean:
|
2021-05-27 13:59:00 -04:00
|
|
|
|
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);
|
2010-04-29 15:45:57 +00:00
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
|
|
case var_uinteger:
|
2021-05-27 13:59:00 -04:00
|
|
|
|
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,
|
2021-05-27 13:59:00 -04:00
|
|
|
|
show_doc, help_doc, get_set_value,
|
|
|
|
|
|
get_show_value, set_list, show_list);
|
2010-04-29 15:45:57 +00:00
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
|
|
case var_integer:
|
2021-05-27 13:59:00 -04:00
|
|
|
|
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,
|
2021-05-27 13:59:00 -04:00
|
|
|
|
show_doc, help_doc, get_set_value,
|
|
|
|
|
|
get_show_value, set_list, show_list);
|
|
|
|
|
|
break;
|
2010-04-29 15:45:57 +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
|
|
|
|
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;
|
|
|
|
|
|
|
2010-04-29 15:45:57 +00:00
|
|
|
|
case var_string:
|
2021-05-27 13:59:00 -04:00
|
|
|
|
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,
|
2021-05-27 13:59:00 -04:00
|
|
|
|
show_doc, help_doc, get_set_value,
|
|
|
|
|
|
get_show_value, set_list, show_list);
|
|
|
|
|
|
break;
|
2010-04-29 15:45:57 +00:00
|
|
|
|
|
|
|
|
|
|
case var_string_noescape:
|
2021-05-27 13:59:00 -04:00
|
|
|
|
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,
|
2021-05-27 13:59:00 -04:00
|
|
|
|
set_doc, show_doc, help_doc,
|
|
|
|
|
|
get_set_value, get_show_value,
|
|
|
|
|
|
set_list, show_list);
|
2010-04-29 15:45:57 +00:00
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
|
|
case var_optional_filename:
|
2021-05-27 13:59:00 -04:00
|
|
|
|
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,
|
2021-05-27 13:59:00 -04:00
|
|
|
|
set_doc, show_doc, help_doc,
|
|
|
|
|
|
get_set_value,
|
|
|
|
|
|
get_show_value, set_list,
|
|
|
|
|
|
show_list);
|
2010-04-29 15:45:57 +00:00
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
|
|
case var_filename:
|
2021-05-27 13:59:00 -04:00
|
|
|
|
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,
|
2021-05-27 13:59:00 -04:00
|
|
|
|
show_doc, help_doc, get_set_value,
|
|
|
|
|
|
get_show_value, set_list, show_list);
|
|
|
|
|
|
break;
|
2010-04-29 15:45:57 +00:00
|
|
|
|
|
|
|
|
|
|
case var_enum:
|
2022-01-04 08:52:40 -07:00
|
|
|
|
/* Initialize the value, just in case. */
|
|
|
|
|
|
self->value.cstringval = self->enumeration[0];
|
2021-05-27 13:59:00 -04:00
|
|
|
|
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);
|
2010-04-29 15:45:57 +00:00
|
|
|
|
break;
|
2021-05-27 13:59:00 -04:00
|
|
|
|
|
2024-10-05 22:27:44 +03:00
|
|
|
|
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;
|
|
|
|
|
|
|
2021-05-27 13:59:00 -04:00
|
|
|
|
default:
|
|
|
|
|
|
gdb_assert_not_reached ("Unhandled parameter class.");
|
2010-04-29 15:45:57 +00:00
|
|
|
|
}
|
2011-03-10 12:29:08 +00:00
|
|
|
|
|
2021-05-27 13:59:00 -04:00
|
|
|
|
/* Register Python objects in both commands' context. */
|
2021-06-25 21:35:40 -04:00
|
|
|
|
commands.set->set_context (self);
|
|
|
|
|
|
commands.show->set_context (self);
|
2021-05-12 13:50:05 -04:00
|
|
|
|
|
|
|
|
|
|
/* We (unfortunately) currently leak the command name. */
|
|
|
|
|
|
cmd_name.release ();
|
2010-04-29 15:45:57 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
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. */
|
2010-04-29 15:45:57 +00:00
|
|
|
|
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))
|
|
|
|
|
|
{
|
2013-11-29 12:00:47 -08:00
|
|
|
|
PyErr_SetString (PyExc_RuntimeError,
|
2010-04-29 15:45:57 +00:00
|
|
|
|
_("The enumeration is not a sequence."));
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
size = PySequence_Size (enum_values);
|
|
|
|
|
|
if (size < 0)
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
if (size == 0)
|
|
|
|
|
|
{
|
2013-11-29 12:00:47 -08:00
|
|
|
|
PyErr_SetString (PyExc_RuntimeError,
|
2010-04-29 15:45:57 +00:00
|
|
|
|
_("The enumeration is empty."));
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2017-04-30 23:03:58 -06:00
|
|
|
|
gdb_argv holder (XCNEWVEC (char *, size + 1));
|
|
|
|
|
|
char **enumeration = holder.get ();
|
2010-04-29 15:45:57 +00:00
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < size; ++i)
|
|
|
|
|
|
{
|
Turn gdbpy_ref into a template
This turns gdbpy_ref into a template class, so that it can be used to
wrap subclasses of PyObject. The default argument remains PyObject;
and this necessitated renaming uses of "gdbpy_ref" to "gdbpy_ref<>".
gdb/ChangeLog
2017-02-10 Tom Tromey <tom@tromey.com>
* python/py-ref.h (gdbpy_ref_policy): Now a template.
(gdbpy_ref): Now a template; allow subclasses of PyObject to be
used.
* python/py-arch.c, python/py-bpevent.c, python/py-breakpoint.c,
python/py-cmd.c, python/py-continueevent.c, python/py-event.c,
python/py-exitedevent.c, python/py-finishbreakpoint.c,
python/py-framefilter.c, python/py-function.c,
python/py-inferior.c, python/py-infevents.c,
python/py-linetable.c, python/py-newobjfileevent.c,
python/py-param.c, python/py-prettyprint.c, python/py-ref.h,
python/py-signalevent.c, python/py-stopevent.c,
python/py-symbol.c, python/py-threadevent.c, python/py-type.c,
python/py-unwind.c, python/py-utils.c, python/py-value.c,
python/py-varobj.c, python/py-xmethods.c, python/python.c,
varobj.c: Change gdbpy_ref to gdbpy_ref<>.
2017-02-09 13:16:36 -07:00
|
|
|
|
gdbpy_ref<> item (PySequence_GetItem (enum_values, i));
|
2010-05-17 21:23:25 +00:00
|
|
|
|
|
2016-11-20 10:34:34 -07:00
|
|
|
|
if (item == NULL)
|
2017-04-30 23:03:58 -06:00
|
|
|
|
return 0;
|
2016-11-20 10:34:34 -07:00
|
|
|
|
if (! gdbpy_is_string (item.get ()))
|
2010-04-29 15:45:57 +00:00
|
|
|
|
{
|
2013-11-29 12:00:47 -08:00
|
|
|
|
PyErr_SetString (PyExc_RuntimeError,
|
2010-04-29 15:45:57 +00:00
|
|
|
|
_("The enumeration item not a string."));
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
}
|
2017-04-30 23:03:58 -06:00
|
|
|
|
enumeration[i] = python_string_to_host_string (item.get ()).release ();
|
|
|
|
|
|
if (enumeration[i] == NULL)
|
|
|
|
|
|
return 0;
|
2010-04-29 15:45:57 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
2017-04-30 23:03:58 -06:00
|
|
|
|
self->enumeration = const_cast<const char**> (holder.release ());
|
2010-04-29 15:45:57 +00:00
|
|
|
|
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.
|
2010-10-13 13:24:40 +00:00
|
|
|
|
|
|
|
|
|
|
Returns -1 on error, with a python exception set. */
|
|
|
|
|
|
|
2010-04-29 15:45:57 +00:00
|
|
|
|
static int
|
|
|
|
|
|
parmpy_init (PyObject *self, PyObject *args, PyObject *kwds)
|
|
|
|
|
|
{
|
|
|
|
|
|
parmpy_object *obj = (parmpy_object *) self;
|
2011-06-24 19:47:37 +00:00
|
|
|
|
const char *name;
|
2018-06-20 15:35:04 -06:00
|
|
|
|
gdb::unique_xmalloc_ptr<char> set_doc, show_doc, doc;
|
2010-04-29 15:45:57 +00:00
|
|
|
|
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;
|
2010-04-29 15:45:57 +00:00
|
|
|
|
|
|
|
|
|
|
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;
|
|
|
|
|
|
}
|
|
|
|
|
|
|
2026-06-18 10:00:20 -06:00
|
|
|
|
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
|
2024-10-05 22:27:44 +03:00
|
|
|
|
&& parmclass != param_zuinteger_unlimited && parmclass != param_enum
|
|
|
|
|
|
&& parmclass != param_color)
|
2010-04-29 15:45:57 +00:00
|
|
|
|
{
|
2011-01-06 00:57:05 +00:00
|
|
|
|
PyErr_SetString (PyExc_RuntimeError,
|
|
|
|
|
|
_("Invalid parameter class argument."));
|
2010-04-29 15:45:57 +00:00
|
|
|
|
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)
|
2010-04-29 15:45:57 +00:00
|
|
|
|
{
|
|
|
|
|
|
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)
|
2010-04-29 15:45:57 +00:00
|
|
|
|
{
|
|
|
|
|
|
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;
|
2024-10-05 22:27:44 +03:00
|
|
|
|
obj->value = {}; /* zeros initialization */
|
2010-04-29 15:45:57 +00:00
|
|
|
|
|
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;
|
|
|
|
|
|
|
2021-05-12 13:50:05 -04:00
|
|
|
|
gdb::unique_xmalloc_ptr<char> cmd_name
|
|
|
|
|
|
= gdbpy_parse_command_name (name, &set_list, &setlist);
|
|
|
|
|
|
if (cmd_name == nullptr)
|
2011-09-08 19:51:27 +00:00
|
|
|
|
return -1;
|
2021-05-12 13:50:05 -04:00
|
|
|
|
|
|
|
|
|
|
cmd_name = gdbpy_parse_command_name (name, &show_list, &showlist);
|
|
|
|
|
|
if (cmd_name == nullptr)
|
2010-04-29 15:45:57 +00:00
|
|
|
|
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 ());
|
2010-04-29 15:45:57 +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
|
|
|
|
/* 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;
|
|
|
|
|
|
|
2010-04-29 15:45:57 +00:00
|
|
|
|
Py_INCREF (self);
|
|
|
|
|
|
|
2019-04-03 16:02:42 -06:00
|
|
|
|
try
|
2010-04-29 15:45:57 +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
|
|
|
|
add_setshow_generic (type, extra_literals,
|
|
|
|
|
|
(enum command_class) cmdtype,
|
2021-05-12 13:50:05 -04:00
|
|
|
|
std::move (cmd_name), obj,
|
2018-06-20 15:35:04 -06:00
|
|
|
|
set_doc.get (), show_doc.get (),
|
|
|
|
|
|
doc.get (), set_list, show_list);
|
2010-04-29 15:45:57 +00:00
|
|
|
|
}
|
2019-04-03 15:59:07 -06:00
|
|
|
|
catch (const gdb_exception &except)
|
2010-04-29 15:45:57 +00:00
|
|
|
|
{
|
|
|
|
|
|
Py_DECREF (self);
|
2024-09-24 13:06:32 +02:00
|
|
|
|
return gdbpy_handle_gdb_exception (-1, except);
|
2010-04-29 15:45:57 +00:00
|
|
|
|
}
|
Split TRY_CATCH into TRY + CATCH
This patch splits the TRY_CATCH macro into three, so that we go from
this:
~~~
volatile gdb_exception ex;
TRY_CATCH (ex, RETURN_MASK_ERROR)
{
}
if (ex.reason < 0)
{
}
~~~
to this:
~~~
TRY
{
}
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
~~~
Thus, we'll be getting rid of the local volatile exception object, and
declaring the caught exception in the catch block.
This allows reimplementing TRY/CATCH in terms of C++ exceptions when
building in C++ mode, while still allowing to build GDB in C mode
(using setjmp/longjmp), as a transition step.
TBC, after this patch, is it _not_ valid to have code between the TRY
and the CATCH blocks, like:
TRY
{
}
// some code here.
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
Just like it isn't valid to do that with C++'s native try/catch.
By switching to creating the exception object inside the CATCH block
scope, we can get rid of all the explicitly allocated volatile
exception objects all over the tree, and map the CATCH block more
directly to C++'s catch blocks.
The majority of the TRY_CATCH -> TRY+CATCH+END_CATCH conversion was
done with a script, rerun from scratch at every rebase, no manual
editing involved. After the mechanical conversion, a few places
needed manual intervention, to fix preexisting cases where we were
using the exception object outside of the TRY_CATCH block, and cases
where we were using "else" after a 'if (ex.reason) < 0)' [a CATCH
after this patch]. The result was folded into this patch so that GDB
still builds at each incremental step.
END_CATCH is necessary for two reasons:
First, because we name the exception object in the CATCH block, which
requires creating a scope, which in turn must be closed somewhere.
Declaring the exception variable in the initializer field of a for
block, like:
#define CATCH(EXCEPTION, mask) \
for (struct gdb_exception EXCEPTION; \
exceptions_state_mc_catch (&EXCEPTION, MASK); \
EXCEPTION = exception_none)
would avoid needing END_CATCH, but alas, in C mode, we build with C90,
which doesn't allow mixed declarations and code.
Second, because when TRY/CATCH are wired to real C++ try/catch, as
long as we need to handle cleanup chains, even if there's no CATCH
block that wants to catch the exception, we need for stop at every
frame in the unwind chain and run cleanups, then rethrow. That will
be done in END_CATCH.
After we require C++, we'll still need TRY/CATCH/END_CATCH until
cleanups are completely phased out -- TRY/CATCH in C++ mode will
save/restore the current cleanup chain, like in C mode, and END_CATCH
catches otherwise uncaugh exceptions, runs cleanups and rethrows, so
that C++ cleanups and exceptions can coexist.
IMO, this still makes the TRY/CATCH code look a bit more like a
newcomer would expect, so IMO worth it even if we weren't considering
C++.
gdb/ChangeLog.
2015-03-07 Pedro Alves <palves@redhat.com>
* common/common-exceptions.c (struct catcher) <exception>: No
longer a pointer to volatile exception. Now an exception value.
<mask>: Delete field.
(exceptions_state_mc_init): Remove all parameters. Adjust.
(exceptions_state_mc): No longer pop the catcher here.
(exceptions_state_mc_catch): New function.
(throw_exception): Adjust.
* common/common-exceptions.h (exceptions_state_mc_init): Remove
all parameters.
(exceptions_state_mc_catch): Declare.
(TRY_CATCH): Rename to ...
(TRY): ... this. Remove EXCEPTION and MASK parameters.
(CATCH, END_CATCH): New.
All callers adjusted.
gdb/gdbserver/ChangeLog:
2015-03-07 Pedro Alves <palves@redhat.com>
Adjust all callers of TRY_CATCH to use TRY/CATCH/END_CATCH
instead.
2015-03-07 15:14:14 +00:00
|
|
|
|
|
2010-04-29 15:45:57 +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;
|
2024-10-05 22:27:44 +03:00
|
|
|
|
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
|
|
|
|
}
|
2010-04-29 15:45:57 +00:00
|
|
|
|
|
|
|
|
|
|
/* Initialize the 'parameters' module. */
|
2025-10-21 10:00:20 -06:00
|
|
|
|
static int
|
|
|
|
|
|
gdbpy_initialize_parameters ()
|
2010-04-29 15:45:57 +00:00
|
|
|
|
{
|
|
|
|
|
|
int i;
|
|
|
|
|
|
|
2011-08-05 14:24:10 +00:00
|
|
|
|
parmpy_object_type.tp_new = PyType_GenericNew;
|
2024-09-11 10:35:20 -06:00
|
|
|
|
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;
|
2010-04-29 15:45:57 +00:00
|
|
|
|
|
2022-03-21 10:07:41 -04:00
|
|
|
|
set_doc_cst = PyUnicode_FromString ("set_doc");
|
2010-04-29 15:45:57 +00:00
|
|
|
|
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;
|
2022-03-21 10:07:41 -04:00
|
|
|
|
show_doc_cst = PyUnicode_FromString ("show_doc");
|
2010-04-29 15:45:57 +00:00
|
|
|
|
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;
|
2010-04-29 15:45:57 +00:00
|
|
|
|
|
|
|
|
|
|
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;
|
2010-04-29 15:45:57 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
2024-09-11 10:35:20 -06:00
|
|
|
|
return 0;
|
2010-04-29 15:45:57 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
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);
|
|
|
|
|
|
|
2010-04-29 15:45:57 +00:00
|
|
|
|
|
|
|
|
|
|
|
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 =
|
2010-04-29 15:45:57 +00:00
|
|
|
|
{
|
2012-12-12 16:47:30 +00:00
|
|
|
|
PyVarObject_HEAD_INIT (NULL, 0)
|
2010-04-29 15:45:57 +00:00
|
|
|
|
"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*/
|
2010-04-29 15:45:57 +00:00
|
|
|
|
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 */
|
|
|
|
|
|
};
|