| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
There's a common pattern to call add_basic_prefix_cmd and
add_show_prefix_cmd to add matching set and show commands. Add the
add_setshow_prefix_cmd function to factor that out and use it at a few
places.
Change-Id: I6e9e90a30e9efb7b255bf839cac27b85d7069cfd
|
|
The bug fixed by this [1] patch was caused by an out-of-bounds access to
a value's content. The code gets the value's content (just a pointer)
and then indexes it with a non-sensical index.
This made me think of changing functions that return value contents to
return array_views instead of a plain pointer. This has the advantage
that when GDB is built with _GLIBCXX_DEBUG, accesses to the array_view
are checked, making bugs more apparent / easier to find.
This patch changes the return types of these functions, and updates
callers to call .data() on the result, meaning it's not changing
anything in practice. Additional work will be needed (which can be done
little by little) to make callers propagate the use of array_view and
reap the benefits.
[1] https://sourceware.org/pipermail/gdb-patches/2021-September/182306.html
Change-Id: I5151f888f169e1c36abe2cbc57620110673816f3
|
|
GDB can notify observers when a parameter is changed.
To do that, do_set_command (in gdb/cli/cli-setshow.c) compares the new
value against the old one before updating it, and based on that notifies
observers. This looks like something like:
int valuechanged = 0;
switch (cmd->var.type ())
{
case var_integer:
{
LONGEST new_val = parse_and_eval_long (arg)
if (new_val != cmd->var.get<int> ())
{
cmd->var.get<int> (new_val);
value_changes = 1;
}
}
case var_uinteger:
case var_zuinteger:
{
unsigned int val
= parse_cli_var_uinteger (c->var->type (), &arg, true);
if (c->var->get<unsigned int> () != val)
{
c->var->set<unsigned int> (val);
option_changed = true;
}
}
case...
/* And so on for all possible var_types. */
}
This comparison is done for each possible var_type, which leads to
unnecessary logic duplication.
In this patch I propose to move all those checks in one place within the
setting setter method. This limits the code duplication and simplifies
the do_set_command implementation.
This patch also changes slightly the way a value change is detected.
Instead of comparing the user provided value against the current value
of the setting, we compare the value of the setting before and after the
set operation. This is meant to handle edge cases where trying to set
an unrecognized value would be equivalent to a noop (the actual value
remains unchanged). Doing this requires that the original value needs
to be copied before the update, which can be non trivial for
std::string.
There should be no user visible change introduced by this commit.
Tested on x86_64 GNU/Linux.
[1] https://review.lttng.org/c/binutils-gdb/+/5831/41
Change-Id: If064b9cede3eb56275aacd2b286f74eceb1aed11
|
|
The main motivation behind this improvement is to help the
implementation of a patch Simon Marchi is preparing to fix a bug when
MI or Python try to access parameters that are inferior dependent (see
PR/28085).
This commit extends the previous ones, which introduces the setting
object to represent a static variable whose value can be set or shown
with the appropriate commands. This patch proposes that a setting can
either contain a pointer to a static variable holding a setting, or
pointers to a pair of setter and getter callback functions.
The callbacks functions can be used to retrieve or change the value with
custom logic. This is useful when the source of truth for a given
setting is not contained in the variable pointed to by the setting
instance.
Given that the callback function call is hidden within the setting
abstraction introduced earlier, none of the sites accessing the setting
needs to be updated. The registered getter or setter is used whatever
the way to access it is (through MI, Python, Guile, the "with" command
and the $_gdb_setting / $_gdb_setting_str convenience functions).
All the add_setshow_*_cmd are given a new overload that will accept the
pair of function pointers (set / get functions) instead of the pointer
to a global variable.
Tested on GNU/Linux x86_64 with no regression observed.
Change-Id: Ieb81fef57550632ff66e6aa85f637372a226be8c
Co-authored-by: Simon Marchi <simon.marchi@polymtl.ca>
|
|
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>
|
|
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
|
|
In some situations it is possible that a user might not want GDB to
try and access source code files, for example, the source code might
be stored on a slow to access network file system.
It is almost certainly possible that using some combination of 'set
directories' and/or 'set substitute-path' a user can trick GDB into
being unable to find the source files, but this feels like a rather
crude way to solve the problem.
In this commit a new option is add that stops GDB from opening and
reading the source files. A user can run with source code reading
disabled if this is required, then re-enable later if they decide
that they now want to view the source code.
|
|
For some reason we have two locations where cmd_list_elements are
declared, cli/cli-cmds.h and gdbcmd.h. Worse still there is
duplication between these two locations.
In this commit I have moved all of the cmd_list_element declarations
from gdbcmd.h into cli/cli-cmds.h and removed the duplicates.
There should be no user visible changes after this commit.
|
|
I noticed that value_true is declared in language.h and defined in
language.c. However, as part of the value API, I think it would be
better in one of those files. And, because it is very short, I
changed it to be an inline function in value.h. I've also removed a
comment from the implementation, on the basis that it seems obsolete
-- if the change it suggests was needed, it probably would have been
done by now; and if it is needed in the future, odds are it would be
done differently anyway.
Finally, this patch also changes value_true and value_logical_not to
return a bool, and updates some uses.
|
|
Trivial patch to use bool instead of int.
Change-Id: I9e5f8ee4305272a6671cbaaaf2f0484eff0d1ea5
|
|
I don't understand what the sfunc function type in
cmd_list_element::function is for. Compared to cmd_simple_func_ftype,
it has an extra cmd_list_element parameter, giving the callback access
to the cmd_list_element for the command being invoked. This allows
registering the same callback with many commands, and alter the behavior
using the cmd_list_element's context.
From the comment in cmd_list_element, it sounds like at some point it
was the callback function type for set and show functions, hence the
"s". But nowadays, it's used for many more commands that need to access
the cmd_list_element object (see add_catch_command for example).
I don't really see the point of having sfunc at all, since do_sfunc is
just a trivial shim that changes the order of the arguments. All
commands using sfunc could just as well set cmd_list_element::func to
their callback directly.
Therefore, remove the sfunc field in cmd_list_element and everything
that goes with it. Rename cmd_const_sfunc_ftype to cmd_func_ftype and
use it for cmd_list_element::func, as well as for the add_setshow
commands.
Change-Id: I1eb96326c9b511c293c76996cea0ebc51c70fac0
|
|
After browsing the CLI code for quite a while and trying really hard, I
reached the conclusion that I can't give a meaningful explanation of
what "sfunc" and "cfunc" functions are, in cmd_list_element. I don't
see a logic at all. That makes it very difficult to do any kind of
change. Unless somebody can make sense out of all that, I'd like to try
to retro-fit some logic in the cmd_list_element callback function code
so that we can understand what is going on, do some cleanups and add new
features.
The first change is about "cfunc". I can't figure out what the "c" in
cfunc means. It's not const, because there's already "const" in
"cmd_const_cfunc_ftype", and the previous "cmd_cfunc_ftype" had nothing
const.. It's not "cmd" or "command", because there's already "cmd" in
"cmd_const_cfunc_ftype".
The "main" command callback, cmd_list_element::func, has three
parameters, whereas cfunc has two. It is missing the cmd_list_element
parameter. So the only reason I see for cfunc to exist is to be a shim
between the three and two parameter versions. Most commands don't need
to receive the cmd_list_element object, so adding it everywhere would be
long and would just add more unnecessary boilerplate. So since this is
the "simple" version of the callback, compared to the "full", I suggest
renaming cmd_const_cfunc_ftype into cmd_simple_func_ftype, as well as
everything (like the utility functions) that goes with it.
Change-Id: I4e46cacfd77a66bc1cbf683f6a362072504b7868
|
|
I propose removing the context parameter from add_setshow_enum_cmd. It
was useful before add_setshow_enum_cmd returned both created commands,
as the caller couldn't easily set the context itself. But now, I think
it's fine to just let the caller do it.
gdb/ChangeLog:
* command.h (add_setshow_enum_cmd): Remove context parameter.
* cli/cli-decode.c (add_setshow_enum_cmd): Likewise, and don't
set context.
* cli/cli-style.c (cli_style_option::add_setshow_commands): Set
context here.
Change-Id: I377c4e6820ec9d5069492ed28f4cba342ce1336e
|
|
If something tries to set a context pointer on a cmd_list_element and
m_context is not nullptr, it's likely that two parts of the code are
trying to set different contexts, and one will overwrite the other.
This is almost guaranteed to lead to bad behavior or a crash, as one of
the spots will not be using the data it expects. This happened to me
during development, so I think having this assert would be useful to
catch this problem earlier.
gdb/ChangeLog:
* cli/cli-decode.h (struct cmd_list_element) <set_context>: Add
assert.
Change-Id: I1f2e9fda1bf2bec1b732c9b90e7d7910a97f2ac6
|
|
Straightforward replacement of get_cmd_context / set_cmd_context with
cmd_list_element methods.
gdb/ChangeLog:
* cli/cli-decode.h (struct cmd_list_element) <set_context,
context>: New.
<context>: Rename to...
<m_context>: ... this.
* cli/cli-decode.c (set_cmd_context, get_cmd_context): Remove.
* command.h (set_cmd_context, get_cmd_context): Remove, use
cmd_list_element::set_context and cmd_list_element::context
everywhere instead.
Change-Id: I5016b0079014e3f17d1aa449ada7954473bf2b5d
|
|
Same idea as previous patch, but for add_alias_cmd. Remove the overload
that accepts the target command as a string (the target command name),
leaving only the one that takes the cmd_list_element.
gdb/ChangeLog:
* command.h (add_alias_cmd): Accept target as
cmd_list_element. Update callers.
Change-Id: I546311f411e9e7da9302322d6ffad4e6c56df266
|
|
Same idea as previous patch, but for add_info_alias.
gdb/ChangeLog:
* command.h (add_info_alias): Accept target as
cmd_list_element. Update callers.
Change-Id: If830d423364bf42d7bea5ac4dd3a81adcfce6f7a
|
|
The alias creation functions currently accept a name to specify the
target command. They pass this to add_alias_cmd, which needs to lookup
the target command by name.
Given that:
- We don't support creating an alias for a command before that command
exists.
- We always use add_info_alias just after creating that target command,
and therefore have access to the target command's cmd_list_element.
... change add_com_alias to accept the target command as a
cmd_list_element (other functions are done in subsequent patches). This
ensures we don't create the alias before the target command, because you
need to get the cmd_list_element from somewhere when you call the alias
creation function. And it avoids an unecessary command lookup. So it
seems better to me in every aspect.
gdb/ChangeLog:
* command.h (add_com_alias): Accept target as
cmd_list_element. Update callers.
Change-Id: I24bed7da57221cc77606034de3023fedac015150
|
|
Some add_set_show commands return a single cmd_list_element, the one for
the "set" command. A subsequent patch will need to access the show
command's cmd_list_element as well. Change these functions to return a
new structure type that holds both pointers.
I initially only modified add_setshow_boolean_cmd (the one I needed),
but I think it's better to change the whole chain to keep everything in
sync.
gdb/ChangeLog:
* command.h (set_show_commands): New.
(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):
Return set_show_commands. Adjust callers.
* cli/cli-decode.c (add_setshow_cmd_full): Return
set_show_commands, remove result parameters, adjust callers.
Change-Id: I17492b01b76002d09effc84830f9c6db26f1db7a
|
|
In cli/cli-script.c, process_next_line() allocates memory
which will eventually end up being assigned to the 'next'
field in struct command_line. However, in a case
recurse_read_control_structure returns 'invalid_control'
this memory is leaked. This commit uses std::unique_ptr
as appropriate to prevent this leakage.
This issue was found by coverity scanning.
gdb/ChangeLog:
* cli/cli-script.h (command_line_up): New unique_ptr typedef.
* cli/cli-script.c (multi_line_command_p): Use unique_ptr
command_line_up instead of struct command_line.
(build_command_line): Likewise.
(get_command_line): Update the cmd function call parameter.
(process_next_line): Use unique_ptr command_line_up instead
of struct command_line.
(recurse_read_control_structure): Change the the type of
next to command_line_up.
(read_command_lines_1): Change type of `next' to be
command_line_up and update all references of `next'
accordingly.
|
|
While adding a ui_out::text () overload accepting a std::string, I
noticed that several callers of ui_out::field_string () were converting
std::string instances to char pointers even if not necessary.
gdb/ChangeLog:
* ui-out.c (ui_out::field_string): Add missing style_argument
to the overload accepting a std::string, to make it equivalent
to the char pointer version.
* ui-out.h (class ui_out): Ditto.
* break-catch-sig.c (signal_catchpoint_print_one): Do not
convert std::strings to char pointers before passing them to
ui_out::field_string ().
* break-catch-throw.c (print_one_detail_exception_catchpoint):
Ditto.
* cli/cli-setshow.c (do_show_command): Ditto.
* disasm.c (gdb_pretty_print_disassembler::pretty_print_insn):
Ditto.
* infcmd.c (print_return_value_1): Ditto.
* inferior.c (print_inferior): Ditto.
* linux-thread-db.c (info_auto_load_libthread_db): Ditto.
* mi/mi-cmd-var.c (print_varobj): Ditto.
(mi_cmd_var_set_format): Ditto.
(mi_cmd_var_info_type): Ditto.
(mi_cmd_var_info_expression): Ditto.
(mi_cmd_var_evaluate_expression): Ditto.
(mi_cmd_var_assign): Ditto.
(varobj_update_one): Ditto.
* mi/mi-main.c (list_available_thread_groups): Ditto.
(mi_cmd_data_read_memory_bytes): Ditto.
(mi_cmd_trace_frame_collected): Ditto.
* osdata.c (info_osdata): Ditto.
* probe.c (info_probes_for_spops): Ditto.
* target-connection.c (print_connection): Ditto.
* thread.c (print_thread_info_1): Ditto.
* tracepoint.c (print_one_static_tracepoint_marker): Ditto.
|
|
gdb/ChangeLog:
* ui-out.h (class ui_out): Add ui_out::text accepting a constant
reference to a std::string. Fix all callers using
std::string::c_str.
* ui-out.c (ui_out::text): Ditto.
|
|
Same idea as the previous patches, but for whether a command is a
"command class help" command. I think this one is particularly useful,
because it's not obvious when reading code what "c->func == NULL" means.
Remove the cmd_func_p function, which does kind of the same thing as
cmd_list_element::is_command_class_help (except it doesn't give a clue
about the semantic of a NULL func value).
gdb/ChangeLog:
* cli/cli-decode.h (cmd_list_element) <is_command_class_help>:
New, use it.
* command.h (cmd_func_p): Remove.
* cli/cli-decode.c (cmd_func_p): Remove.
Change-Id: I521a3e1896dc93a5babe1493d18f5eb071e1b3b7
|
|
Same idea as the previous patch, but for prefix instead of alias.
gdb/ChangeLog:
* cli/cli-decode.h (cmd_list_element) <is_prefix>: New, use it.
Change-Id: I76a9d2e82fc8d7429904424674d99ce6f9880e2b
|
|
Add the cmd_list_element::is_alias helper to check whether a command is
an alias. I find it easier to understand the intention in:
if (c->is_alias ())
than
if (c->alias_target != nullptr)
Change all the spots that are reading alias_target just to compare it to
NULL/nullptr to use is_alias instead.
gdb/ChangeLog:
* cli/cli-decode.h (cmd_list_element) <is_alias>: New, use it.
Change-Id: I26ed56f99ee47fe884fdfedf87016501631693ce
|
|
cmd_pointer is another field whose name I found really not clear. Yes,
it's a pointer to a command, the type tells me that. But what's the
relationship of that command to the current command? This field
contains, for an alias, the command that it aliases. So I think that
the name "alias_target" would be more appropriate.
Also, rename "old" parameters to "target" in the functions that add
aliases.
gdb/ChangeLog:
* cli/cli-decode.h (cmd_list_element) <cmd_pointer>: Rename
to...
<alias_target>: ... this.
(add_alias_cmd): Rename old to target.
(add_info_alias): Rename old_name to target_name.
(add_com_alias): Likewise.
Change-Id: I8db36c6dd799fae155f7acd3805f6d62d98befa9
|
|
While browsing this code, I found the name "prefixlist" really
confusing. I kept reading it as "list of prefixes". Which it isn't:
it's a list of sub-commands, for a prefix command. I think that
renaming it to "subcommands" would make things clearer.
gdb/ChangeLog:
* Rename "prefixlist" parameters to "subcommands" throughout.
* cli/cli-decode.h (cmd_list_element) <prefixlist>: Rename to...
<subcommands>: ... this.
* cli/cli-decode.c (lookup_cmd_for_prefixlist): Rename to...
(lookup_cmd_with_subcommands): ... this.
Change-Id: I150da10d03052c2420aa5b0dee41f422e2a97928
|
|
I don't think this can ever happen, that we add an alias command and
pass a nullptr old (target) command. Remove the "if" handling this,
replace with an assert.
gdb/ChangeLog:
* cli/cli-decode.c (add_alias_cmd): Don't handle old == 0.
Change-Id: Ibb39e8dc4e0c465fa42e6826215f30a0a0aef932
|
|
I don't think this method really benefits from being implemented in the
header file, especially because it's recursive, it can't be inlined.
Move it to the source file, so it's no re-compiled by every CU
including cli/cli-decode.h.
I also noticed this method could be const, make it so.
gdb/ChangeLog:
* cli/cli-decode.h (prefixname): Make const, move implementation
to cli/cli-decode.c.
* cli/cli-decode.c (cmd_list_element::prefixname): New.
Change-Id: I1597cace98d9a4ba71f51f1f495e73cc07b5dcf3
|
|
This is unused, remove it.
gdb/ChangeLog:
* cli/cli-decode.h (struct cmd_list_element) <pre_show_hook>:
Remove.
* cli/cli-setshow.c (do_show_command): Adjust.
Change-Id: Ib9cd79d842550392b062309e1e5c079ad5d7571a
|
|
Previously, the prefixname field of struct cmd_list_element was manually
set for prefix commands. This seems verbose and error prone as it
required every single call to functions adding prefix commands to
specify the prefix name while the same information can be easily
generated.
Historically, this was not possible as the prefix field was null for
many commands, but this was fixed in commit
3f4d92ebdf7f848b5ccc9e8d8e8514c64fde1183 by Philippe Waroquiers, so
we can rely on the prefix field being set when generating the prefix
name.
This commit also fixes a use after free in this scenario:
* A command gets created via Python (using the gdb.Command class).
The prefix name member is dynamically allocated.
* An alias to the new command is created. The alias's prefixname is set
to point to the prefixname for the original command with a direct
assignment.
* A new command with the same name as the Python command is created.
* The object for the original Python command gets freed and its
prefixname gets freed as well.
* The alias is updated to point to the new command, but its prefixname
is not updated so it keeps pointing to the freed one.
gdb/ChangeLog:
* command.h (add_prefix_cmd): Remove the prefixname argument as
it can now be generated automatically. Update all callers.
(add_basic_prefix_cmd): Ditto.
(add_show_prefix_cmd): Ditto.
(add_prefix_cmd_suppress_notification): Ditto.
(add_abbrev_prefix_cmd): Ditto.
* cli/cli-decode.c (add_prefix_cmd): Ditto.
(add_basic_prefix_cmd): Ditto.
(add_show_prefix_cmd): Ditto.
(add_prefix_cmd_suppress_notification): Ditto.
(add_prefix_cmd_suppress_notification): Ditto.
(add_abbrev_prefix_cmd): Ditto.
* cli/cli-decode.h (struct cmd_list_element): Replace the
prefixname member variable with a method which generates the
prefix name at runtime. Update all code reading the prefix
name to use the method, and remove all code setting it.
* python/py-cmd.c (cmdpy_destroyer): Remove code to free the
prefixname member as it's now a method.
(cmdpy_function): Determine if the command is a prefix by
looking at prefixlist, not prefixname.
|
|
This structure declaration is over-indented, fix that.
gdb/ChangeLog:
* cli/cli-decode.h (struct cmd_list_element): Fix indentation.
Change-Id: I17c9cd739a233239b3add72f4fce7947c20907cd
|
|
Before this patch:
(gdb) source ~/script.scm
ERROR: In procedure apply-smob/1:
ERROR: In procedure primitive-load-path: Unable to find file "~/script.scm" in load path
Error while executing Scheme code.
(gdb)
This is because the path is not tilde expanded. In contrast, when
sourcing a .py or .gdb script the path is tilde expanded.
This commit fixes this oversight, and allows the above source command
to work as expected.
The tilde expansion is done in the generic GDB code before we call the
sourcer function for any particular extension language.
gdb/ChangeLog:
* cli/cli-cmds.c: Add 'gdbsupport/gdb_tilde_expand.h'
include.
(source_script_with_search): Perform tilde expansion.
gdb/testsuite/ChangeLog:
* gdb.guile/guile.exp: Add an extra test.
|
|
In code dealing with commands, there's a pattern repeated a few times of
calling lookup_cmd with some speficic arguments and then using strcmp
on the returned command to check for an exact match.
As a later patch would add a few more similar lines of code, this patch
adds a new lookup_cmd_exact function which simplify this use case.
gdb/ChangeLog:
* cli/cli-decode.c (lookup_cmd_exact): Add.
* cli/cli-script.c (do_define_command): Use lookup_cmd_exact.
(define_prefix_command): Ditto.
* command.h: Add lookup_cmd_exact.
|
|
Bug 27773 shows that passing a filename in a non-existent directory to
the "dump binary" command leads to a gdb crash. This is because the
gdb_fopen_cloexec in dump_binary_file fails (returns nullptr) and the
return value is not checked. Fix that by erroring out if
gdb_fopen_cloexec fails.
gdb/ChangeLog:
PR gdb/27773
* cli/cli-dump.c (dump_binary_file): Check result of
gdb_fopen_cloexec.
gdb/testsuite/ChangeLog:
PR gdb/27773
* gdb.base/dump.exp: Test dump to non-existent dir.
Change-Id: Iea89a3bf9e6b9dcc31142faa5ae17bc855759328
|
|
Give a name to each observer, this will help produce more meaningful
debug message.
gdbsupport/ChangeLog:
* observable.h (class observable) <struct observer> <observer>:
Add name parameter.
<name>: New field.
<attach>: Add name parameter, update all callers.
Change-Id: Ie0cc4664925215b8d2b09e026011b7803549fba0
|
|
This patch addresses PR gdb/27133. Before it, the following succession
of commands would cause gdb to crash:
set logging redirect on
set logging debugredirect on
set logging on
The problem eventually comes down to a use after free. The function
cli_interp_base::set_logging is called with a unique_ptr argument that
holds a pointer to the redirection file. In the problematic use case,
no-one ever took ownership of that pointer (as far as unique_ptr is
concerned), so the call to its dtor at the end of the function causes
the file object to be deleted. Any later use of the pointer to the
redirection file is therefore an error.
This patch ensures that the unique_ptr is released when required (so it
does not assume ownership anymore). The internal logic of
cli_interp_base::set_logging takes care of freeing the ui_file when it
is not necessary anymore using the saved_output.file_to_delete field.
gdb/ChangeLog:
PR gdb/27133
* cli/cli-interp.c (cli_interp_base::set_logging): Ensure the
unique_ptr is released when the wrapped pointer is kept for later
use.
gdb/testsuite/ChangeLog:
PR gdb/27133
* gdb.base/ui-redirect.exp: Add test case that ensures that
redirecting both logging and debug does not cause gdb to crash.
|
|
This commit adds a new 'version' style, which replaces the hard coded
styling currently used for GDB's version string. GDB's version number
is displayed:
1. In the output of 'show version', and
2. When GDB starts up (without the --quiet option).
This new style can only ever affect the first of these two cases as
the second case is printed before GDB has processed any initialization
files, or processed any GDB commands passed on the command line.
However, because the first case exists I think this commit makes
sense, it means the style is no longer hard coded into GDB, and we can
add some tests that the style can be enabled/disabled correctly.
This commit is an alternative to a patch Tom posted here:
https://sourceware.org/pipermail/gdb-patches/2020-June/169820.html
I've used the style name 'version' instead of 'startup' to reflect
what the style is actually used for. If other parts of the startup
text end up being highlighted I imagine they would get their own
styles based on what is being highlighted. I feel this is more inline
with the other style names that are already in use within GDB.
I also decoupled adding this style from the idea of startup options,
and the possibility of auto-saving startup options. Those ideas can
be explored in later patches.
This commit should probably be considered only a partial solution to
issue PR cli/25956. The colours of the style are no longer hard
coded, however, it is still impossible to change the styling of the
version string displayed during startup, so in one sense, the styling
of that string is still "hard coded". A later patch will hopefully
extend GDB to allow it to adjust the version styling before the
initial version string is printed.
gdb/ChangeLog:
PR cli/25956
* cli/cli-style.c: Add 'cli/cli-setshow.h' include.
(version_style): Define.
(cli_style_option::cli_style_option): Add intensity parameter, and
use as appropriate.
(_initialize_cli_style): Register version style set/show commands.
* cli/cli-style.h (cli_style_option): Add intensity parameter.
(version_style): Declare.
* top.c (print_gdb_version): Use version_stype, and styled_string
to print the GDB version string.
gdb/doc/ChangeLog:
PR cli/25956
* gdb.texinfo (Output Styling): Document version style.
gdb/testsuite/ChangeLog:
PR cli/25956
* gdb.base/style.exp (run_style_tests): Add version string test.
(test_startup_version_string): Use version style name.
* lib/gdb-utils.exp (style): Handle version style name.
|
|
Commands "set debug remote" and "set remotetimeout" are defined in
cli/cli-cmds.c, I think it would make more sense for them to be in
remote.c.
gdb/ChangeLog:
* cli/cli-cmds.c (show_remote_debug): Remove.
(show_remote_timeout): Remove.
(_initialize_cli_cmds): Don't register commands.
* remote.c (show_remote_debug): Move here.
(show_remote_timeout): Move here.
(_initialize_remote): Register commands.
Change-Id: Ic4d81888aa4f8dde89d1d29397ef19a08951b80b
|
|
This commits the result of running gdb/copyright.py as per our Start
of New Year procedure...
gdb/ChangeLog
Update copyright year range in copyright header of all GDB files.
|
|
"document" command executed in python, gdb.execute("document
<comname>\n...\nend\n"), will wait for user input. Python extension stops
working from that point.
multi-line suport was introduced in commit 56bcdbea2. But "document" support
seem to be implemented.
gdb/ChangeLog:
2020-12-02 Rae Kim <rae.kim@gmail.com>
* cli/cli-script.c (do_document_command): Rename from
document_command. Handle multi-line input.
(multi_line_command_p): Handle document_control.
(build_command_line): Likewise.
(execute_control_command_1): Likewise.
(process_next_line): Likewise.
(document_command): Call do_document_command.
* cli/cli-script.h (enum command_control_type): Add
document_control.
gdb/testsuite/ChangeLog:
2020-12-02 Rae Kim <rae.kim@gmail.com>
* gdb.base/document.exp: New test.
Change-Id: Ice262b980c05051de4c106af9f3fde5b2a6df6fe
|
|
After Andrew's latest patch, I noticed that the deprecation warnings
could use the (so-called) title style when printing command names.
This patch implements this idea.
gdb/ChangeLog
2020-12-15 Tom Tromey <tromey@adacore.com>
* cli/cli-decode.c (deprecated_cmd_warning): Use title style for
command names.
gdb/testsuite/ChangeLog
2020-12-15 Tom Tromey <tromey@adacore.com>
* gdb.base/style.exp: Add deprecation tests.
|
|
We currently have two flushing commands 'flushregs' and 'maint
flush-symbol-cache'. I'm planning to add at least one more so I
thought it might be nice if we bundled these together into one place.
And so I created the 'maint flush ' command prefix. Currently there
are two commands:
(gdb) maint flush symbol-cache
(gdb) maint flush register-cache
Unfortunately, even though both of the existing flush commands are
maintenance commands, I don't know how keen we about deleting existing
commands for fear of breaking things in the wild. So, both of the
existing flush commands 'maint flush-symbol-cache' and 'flushregs' are
still around as deprecated aliases to the new commands.
I've updated the testsuite to use the new command syntax, and updated
the documentation too.
gdb/ChangeLog:
* NEWS: Mention new commands, and that the old commands are now
deprecated.
* cli/cli-cmds.c (maintenanceflushlist): Define.
* cli/cli-cmds.h (maintenanceflushlist): Declare.
* maint.c (_initialize_maint_cmds): Initialise
maintenanceflushlist.
* regcache.c: Add 'cli/cli-cmds.h' include.
(reg_flush_command): Add header comment.
(_initialize_regcache): Create new 'maint flush register-cache'
command, make 'flushregs' an alias.
* symtab.c: Add 'cli/cli-cmds.h' include.
(_initialize_symtab): Create new 'maint flush symbol-cache'
command, make old command an alias.
gdb/doc/ChangeLog:
* gdb.texinfo (Symbols): Document 'maint flush symbol-cache'.
(Maintenance Commands): Document 'maint flush register-cache'.
gdb/testsuite/ChangeLog:
* gdb.base/c-linkage-name.exp: Update to use new 'maint flush ...'
commands.
* gdb.base/killed-outside.exp: Likewise.
* gdb.opt/inline-bt.exp: Likewise.
* gdb.perf/gmonster-null-lookup.py: Likewise.
* gdb.perf/gmonster-print-cerr.py: Likewise.
* gdb.perf/gmonster-ptype-string.py: Likewise.
* gdb.python/py-unwind.exp: Likewise.
|
|
Consider this GDB session:
(gdb) define set xxx_yyy
Type commands for definition of "set xxx_yyy".
End with a line saying just "end".
>echo in set xxx_yyy command\n
>end
(gdb) alias set qqq_aaa=set xxx_yyy
(gdb) maintenance deprecate set qqq_aaa
(gdb) set qqq_aaa
Warning: 'qqq_aaa', an alias for the command 'xxx_yyy' is deprecated.
No alternative known.
in set xxx_yyy command
(gdb)
Notice the warning mentions 'qqq_aaa' and 'xxx_yyy', I consider this
to be wrong. I think the proper warning should read:
(gdb) set qqq_aaa
Warning: 'set qqq_aaa', an alias for the command 'set xxx_yyy', is deprecated.
No alternative known.
With the 'set' prefixes added and a comma before the final 'is
deprecated'. That is what this patch does. The expected results are
updated as needed.
gdb/ChangeLog:
* cli/cli-decode.c (deprecated_cmd_warning): Ignore the prefix
result from lookup_cmd_composition_1, use the prefixes from both
the command and the alias instead.
(lookup_cmd_composition_1): Initial prefix command is the based on
the search list being passed in. Simplify the logic for tracking
the prefix command. Replace a use of alloca with a local
std::string.
gdb/testsuite/ChangeLog:
* gdb.base/commands.exp: Update expected results.
|
|
Rewrite deprecated_cmd_warning to be i18n friendly. While I'm going
through the function I also cleaned up some whitespace issues,
replaced uses of NULL with nullptr, and moved some comments to avoid
having to add { ... }.
Though the message being printed has a 'Warning: ' prefix I could have
changed from using printf_filtered to use warning, however, I haven't
done that in this commit as that would change what GDB outputs and I
wanted this commit NOT to change the output.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* cli/cli-decode.c (deprecated_cmd_warning): Use nullptr instead
of NULL. Don't print message piece by piece, but sentence at a
time to allow internationalisation. Some whitespace cleanup.
|
|
I noticed that deprecated aliases that have a prefix don't give a
deprecated command warning. For example looking in mi/mi-main.c we
see this:
c = add_alias_cmd ("target-async", "mi-async", class_run, 0, &setlist);
deprecate_cmd (c, "set mi-async");
c = add_alias_cmd ("target-async", "mi-async", class_run, 0, &showlist);
deprecate_cmd (c, "show mi-async");
So both 'set target-async' and 'show target-async' are deprecated and
should be giving a warning, however, in use we see no warning given.
This is a consequence of how the code that should give this
warning (deprecated_cmd_warning) performs a second command lookup in
order to distinguish between aliases and real commands, and that the
code that calls this (lookup_cmd_1) strips off prefix commands as it
calls itself recursively.
As a result when we are considering an alias like 'set target-async'
we first enter lookup_cmd_1 with text = "set target-async", we spot
the 'set' command prefix and then recursively call lookup_cmd_1 with
text = "target-async".
We spot that 'target-async' is a known alias but that it is
deprecated, and so call deprecated_cmd_warning passing in the value of
text, which remember is now "target-async".
In deprecated_cmd_warning we again perform a command lookup starting
from the top-level cmdlist, but now we're trying to find just
"target-async", this fails (as this command requires the 'set' prefix,
and so no warning is given.
I resolved this issue by passing a command list to the function
deprecated_cmd_warning, this is the list in which the command can be
found.
A new test is added to cover this case.
However, there is an additional problem which will be addressed in a
subsequent patch.
Consider this GDB session:
(gdb) define set xxx_yyy
Type commands for definition of "set xxx_yyy".
End with a line saying just "end".
>echo in set xxx_yyy command\n
>end
(gdb) alias set qqq_aaa=set xxx_yyy
(gdb) maintenance deprecate set qqq_aaa
(gdb) set qqq_aaa
Warning: 'qqq_aaa', an alias for the command 'xxx_yyy' is deprecated.
No alternative known.
in set xxx_yyy command
(gdb)
Notice the warning mentions 'qqq_aaa' and 'xxx_yyy', I consider this
to be wrong. I think the proper warning should read:
(gdb) set qqq_aaa
Warning: 'set qqq_aaa', an alias for the command 'set xxx_yyy' is deprecated.
No alternative known.
With the 'set' prefixes added. A later patch will resolve this
issue.
gdb/ChangeLog:
PR cli/15104
* cli/cli-decode.c (lookup_cmd_1): Pass command list to
deprecated_cmd_warning.
(deprecated_cmd_warning): Take extra parameter, call
lookup_cmd_composition_1 and pass new parameter through.
(lookup_cmd_composition_1): New function, takes implementation of
lookup_cmd_composition but with extra parameter.
(lookup_cmd_composition): Now calls lookup_cmd_composition_1
passing in cmdlist.
* command.h (deprecated_cmd_warning): Add extra parameter to
declaration.
* top.c (execute_command): Pass cmdlist to deprecated_cmd_warning.
gdb/testsuite/ChangeLog:
PR cli/15104
* gdb.base/commands.exp: Add additional tests.
* gdb.base/completion.exp: Add additional tests.
|
|
Consider this gdb session, where on line #3 tab completion is used:
(gdb) alias xxx_yyy_zzz=break
(gdb) maint deprecate xxx_yyy_zzz
(gdb) xxx_yyy_<TAB>
The third line then updates to look like this:
(gdb) xxx_yyy_Warning: 'xxx_yyy_zzz', an alias for the command 'break' is deprecated.
No alternative known.
zzz
What's happened is during tab completion the alias has been resolved
to the actual command being aliased, and at this stage the warning is
issued. Clearly this is not what we want during tab completion.
In this commit I add a new parameter to the lookup function, a boolean
that indicates if the lookup is being done as part of completion.
This flag is used to suppress the warning. Now we get the expected
behaviour, the alias completes without any warning, but the warning is
still given once the user executes the alias.
gdb/ChangeLog:
* cli/cli-decode.c (lookup_cmd_1): Move header comment into
command.h, add extra parameter, and use this to guard giving a
warning.
* command.h (lookup_cmd_1): Add comment from cli/cli-decode.c,
include argument names in declaration, add new argument.
* completer.c (complete_line_internal_1): Remove unneeded
brackets, pass extra argument to lookup_cmd_1.
gdb/testsuite/ChangeLog:
* gdb.base/completion.exp: Add additional tests.
|
|
Many spots incorrectly use only spaces for indentation (for example,
there are a lot of spots in ada-lang.c). I've always found it awkward
when I needed to edit one of these spots: do I keep the original wrong
indentation, or do I fix it? What if the lines around it are also
wrong, do I fix them too? I probably don't want to fix them in the same
patch, to avoid adding noise to my patch.
So I propose to fix as much as possible once and for all (hopefully).
One typical counter argument for this is that it makes code archeology
more difficult, because git-blame will show this commit as the last
change for these lines. My counter counter argument is: when
git-blaming, you often need to do "blame the file at the parent commit"
anyway, to go past some other refactor that touched the line you are
interested in, but is not the change you are looking for. So you
already need a somewhat efficient way to do this.
Using some interactive tool, rather than plain git-blame, makes this
trivial. For example, I use "tig blame <file>", where going back past
the commit that changed the currently selected line is one keystroke.
It looks like Magit in Emacs does it too (though I've never used it).
Web viewers of Github and Gitlab do it too. My point is that it won't
really make archeology more difficult.
The other typical counter argument is that it will cause conflicts with
existing patches. That's true... but it's a one time cost, and those
are not conflicts that are difficult to resolve. I have also tried "git
rebase --ignore-whitespace", it seems to work well. Although that will
re-introduce the faulty indentation, so one needs to take care of fixing
the indentation in the patch after that (which is easy).
gdb/ChangeLog:
* aarch64-linux-tdep.c: Fix indentation.
* aarch64-ravenscar-thread.c: Fix indentation.
* aarch64-tdep.c: Fix indentation.
* aarch64-tdep.h: Fix indentation.
* ada-lang.c: Fix indentation.
* ada-lang.h: Fix indentation.
* ada-tasks.c: Fix indentation.
* ada-typeprint.c: Fix indentation.
* ada-valprint.c: Fix indentation.
* ada-varobj.c: Fix indentation.
* addrmap.c: Fix indentation.
* addrmap.h: Fix indentation.
* agent.c: Fix indentation.
* aix-thread.c: Fix indentation.
* alpha-bsd-nat.c: Fix indentation.
* alpha-linux-tdep.c: Fix indentation.
* alpha-mdebug-tdep.c: Fix indentation.
* alpha-nbsd-tdep.c: Fix indentation.
* alpha-obsd-tdep.c: Fix indentation.
* alpha-tdep.c: Fix indentation.
* amd64-bsd-nat.c: Fix indentation.
* amd64-darwin-tdep.c: Fix indentation.
* amd64-linux-nat.c: Fix indentation.
* amd64-linux-tdep.c: Fix indentation.
* amd64-nat.c: Fix indentation.
* amd64-obsd-tdep.c: Fix indentation.
* amd64-tdep.c: Fix indentation.
* amd64-windows-tdep.c: Fix indentation.
* annotate.c: Fix indentation.
* arc-tdep.c: Fix indentation.
* arch-utils.c: Fix indentation.
* arch/arm-get-next-pcs.c: Fix indentation.
* arch/arm.c: Fix indentation.
* arm-linux-nat.c: Fix indentation.
* arm-linux-tdep.c: Fix indentation.
* arm-nbsd-tdep.c: Fix indentation.
* arm-pikeos-tdep.c: Fix indentation.
* arm-tdep.c: Fix indentation.
* arm-tdep.h: Fix indentation.
* arm-wince-tdep.c: Fix indentation.
* auto-load.c: Fix indentation.
* auxv.c: Fix indentation.
* avr-tdep.c: Fix indentation.
* ax-gdb.c: Fix indentation.
* ax-general.c: Fix indentation.
* bfin-linux-tdep.c: Fix indentation.
* block.c: Fix indentation.
* block.h: Fix indentation.
* blockframe.c: Fix indentation.
* bpf-tdep.c: Fix indentation.
* break-catch-sig.c: Fix indentation.
* break-catch-syscall.c: Fix indentation.
* break-catch-throw.c: Fix indentation.
* breakpoint.c: Fix indentation.
* breakpoint.h: Fix indentation.
* bsd-uthread.c: Fix indentation.
* btrace.c: Fix indentation.
* build-id.c: Fix indentation.
* buildsym-legacy.h: Fix indentation.
* buildsym.c: Fix indentation.
* c-typeprint.c: Fix indentation.
* c-valprint.c: Fix indentation.
* c-varobj.c: Fix indentation.
* charset.c: Fix indentation.
* cli/cli-cmds.c: Fix indentation.
* cli/cli-decode.c: Fix indentation.
* cli/cli-decode.h: Fix indentation.
* cli/cli-script.c: Fix indentation.
* cli/cli-setshow.c: Fix indentation.
* coff-pe-read.c: Fix indentation.
* coffread.c: Fix indentation.
* compile/compile-cplus-types.c: Fix indentation.
* compile/compile-object-load.c: Fix indentation.
* compile/compile-object-run.c: Fix indentation.
* completer.c: Fix indentation.
* corefile.c: Fix indentation.
* corelow.c: Fix indentation.
* cp-abi.h: Fix indentation.
* cp-namespace.c: Fix indentation.
* cp-support.c: Fix indentation.
* cp-valprint.c: Fix indentation.
* cris-linux-tdep.c: Fix indentation.
* cris-tdep.c: Fix indentation.
* darwin-nat-info.c: Fix indentation.
* darwin-nat.c: Fix indentation.
* darwin-nat.h: Fix indentation.
* dbxread.c: Fix indentation.
* dcache.c: Fix indentation.
* disasm.c: Fix indentation.
* dtrace-probe.c: Fix indentation.
* dwarf2/abbrev.c: Fix indentation.
* dwarf2/attribute.c: Fix indentation.
* dwarf2/expr.c: Fix indentation.
* dwarf2/frame.c: Fix indentation.
* dwarf2/index-cache.c: Fix indentation.
* dwarf2/index-write.c: Fix indentation.
* dwarf2/line-header.c: Fix indentation.
* dwarf2/loc.c: Fix indentation.
* dwarf2/macro.c: Fix indentation.
* dwarf2/read.c: Fix indentation.
* dwarf2/read.h: Fix indentation.
* elfread.c: Fix indentation.
* eval.c: Fix indentation.
* event-top.c: Fix indentation.
* exec.c: Fix indentation.
* exec.h: Fix indentation.
* expprint.c: Fix indentation.
* f-lang.c: Fix indentation.
* f-typeprint.c: Fix indentation.
* f-valprint.c: Fix indentation.
* fbsd-nat.c: Fix indentation.
* fbsd-tdep.c: Fix indentation.
* findvar.c: Fix indentation.
* fork-child.c: Fix indentation.
* frame-unwind.c: Fix indentation.
* frame-unwind.h: Fix indentation.
* frame.c: Fix indentation.
* frv-linux-tdep.c: Fix indentation.
* frv-tdep.c: Fix indentation.
* frv-tdep.h: Fix indentation.
* ft32-tdep.c: Fix indentation.
* gcore.c: Fix indentation.
* gdb_bfd.c: Fix indentation.
* gdbarch.sh: Fix indentation.
* gdbarch.c: Re-generate
* gdbarch.h: Re-generate.
* gdbcore.h: Fix indentation.
* gdbthread.h: Fix indentation.
* gdbtypes.c: Fix indentation.
* gdbtypes.h: Fix indentation.
* glibc-tdep.c: Fix indentation.
* gnu-nat.c: Fix indentation.
* gnu-nat.h: Fix indentation.
* gnu-v2-abi.c: Fix indentation.
* gnu-v3-abi.c: Fix indentation.
* go32-nat.c: Fix indentation.
* guile/guile-internal.h: Fix indentation.
* guile/scm-cmd.c: Fix indentation.
* guile/scm-frame.c: Fix indentation.
* guile/scm-iterator.c: Fix indentation.
* guile/scm-math.c: Fix indentation.
* guile/scm-ports.c: Fix indentation.
* guile/scm-pretty-print.c: Fix indentation.
* guile/scm-value.c: Fix indentation.
* h8300-tdep.c: Fix indentation.
* hppa-linux-nat.c: Fix indentation.
* hppa-linux-tdep.c: Fix indentation.
* hppa-nbsd-nat.c: Fix indentation.
* hppa-nbsd-tdep.c: Fix indentation.
* hppa-obsd-nat.c: Fix indentation.
* hppa-tdep.c: Fix indentation.
* hppa-tdep.h: Fix indentation.
* i386-bsd-nat.c: Fix indentation.
* i386-darwin-nat.c: Fix indentation.
* i386-darwin-tdep.c: Fix indentation.
* i386-dicos-tdep.c: Fix indentation.
* i386-gnu-nat.c: Fix indentation.
* i386-linux-nat.c: Fix indentation.
* i386-linux-tdep.c: Fix indentation.
* i386-nto-tdep.c: Fix indentation.
* i386-obsd-tdep.c: Fix indentation.
* i386-sol2-nat.c: Fix indentation.
* i386-tdep.c: Fix indentation.
* i386-tdep.h: Fix indentation.
* i386-windows-tdep.c: Fix indentation.
* i387-tdep.c: Fix indentation.
* i387-tdep.h: Fix indentation.
* ia64-libunwind-tdep.c: Fix indentation.
* ia64-libunwind-tdep.h: Fix indentation.
* ia64-linux-nat.c: Fix indentation.
* ia64-linux-tdep.c: Fix indentation.
* ia64-tdep.c: Fix indentation.
* ia64-tdep.h: Fix indentation.
* ia64-vms-tdep.c: Fix indentation.
* infcall.c: Fix indentation.
* infcmd.c: Fix indentation.
* inferior.c: Fix indentation.
* infrun.c: Fix indentation.
* iq2000-tdep.c: Fix indentation.
* language.c: Fix indentation.
* linespec.c: Fix indentation.
* linux-fork.c: Fix indentation.
* linux-nat.c: Fix indentation.
* linux-tdep.c: Fix indentation.
* linux-thread-db.c: Fix indentation.
* lm32-tdep.c: Fix indentation.
* m2-lang.c: Fix indentation.
* m2-typeprint.c: Fix indentation.
* m2-valprint.c: Fix indentation.
* m32c-tdep.c: Fix indentation.
* m32r-linux-tdep.c: Fix indentation.
* m32r-tdep.c: Fix indentation.
* m68hc11-tdep.c: Fix indentation.
* m68k-bsd-nat.c: Fix indentation.
* m68k-linux-nat.c: Fix indentation.
* m68k-linux-tdep.c: Fix indentation.
* m68k-tdep.c: Fix indentation.
* machoread.c: Fix indentation.
* macrocmd.c: Fix indentation.
* macroexp.c: Fix indentation.
* macroscope.c: Fix indentation.
* macrotab.c: Fix indentation.
* macrotab.h: Fix indentation.
* main.c: Fix indentation.
* mdebugread.c: Fix indentation.
* mep-tdep.c: Fix indentation.
* mi/mi-cmd-catch.c: Fix indentation.
* mi/mi-cmd-disas.c: Fix indentation.
* mi/mi-cmd-env.c: Fix indentation.
* mi/mi-cmd-stack.c: Fix indentation.
* mi/mi-cmd-var.c: Fix indentation.
* mi/mi-cmds.c: Fix indentation.
* mi/mi-main.c: Fix indentation.
* mi/mi-parse.c: Fix indentation.
* microblaze-tdep.c: Fix indentation.
* minidebug.c: Fix indentation.
* minsyms.c: Fix indentation.
* mips-linux-nat.c: Fix indentation.
* mips-linux-tdep.c: Fix indentation.
* mips-nbsd-tdep.c: Fix indentation.
* mips-tdep.c: Fix indentation.
* mn10300-linux-tdep.c: Fix indentation.
* mn10300-tdep.c: Fix indentation.
* moxie-tdep.c: Fix indentation.
* msp430-tdep.c: Fix indentation.
* namespace.h: Fix indentation.
* nat/fork-inferior.c: Fix indentation.
* nat/gdb_ptrace.h: Fix indentation.
* nat/linux-namespaces.c: Fix indentation.
* nat/linux-osdata.c: Fix indentation.
* nat/netbsd-nat.c: Fix indentation.
* nat/x86-dregs.c: Fix indentation.
* nbsd-nat.c: Fix indentation.
* nbsd-tdep.c: Fix indentation.
* nios2-linux-tdep.c: Fix indentation.
* nios2-tdep.c: Fix indentation.
* nto-procfs.c: Fix indentation.
* nto-tdep.c: Fix indentation.
* objfiles.c: Fix indentation.
* objfiles.h: Fix indentation.
* opencl-lang.c: Fix indentation.
* or1k-tdep.c: Fix indentation.
* osabi.c: Fix indentation.
* osabi.h: Fix indentation.
* osdata.c: Fix indentation.
* p-lang.c: Fix indentation.
* p-typeprint.c: Fix indentation.
* p-valprint.c: Fix indentation.
* parse.c: Fix indentation.
* ppc-linux-nat.c: Fix indentation.
* ppc-linux-tdep.c: Fix indentation.
* ppc-nbsd-nat.c: Fix indentation.
* ppc-nbsd-tdep.c: Fix indentation.
* ppc-obsd-nat.c: Fix indentation.
* ppc-ravenscar-thread.c: Fix indentation.
* ppc-sysv-tdep.c: Fix indentation.
* ppc64-tdep.c: Fix indentation.
* printcmd.c: Fix indentation.
* proc-api.c: Fix indentation.
* producer.c: Fix indentation.
* producer.h: Fix indentation.
* prologue-value.c: Fix indentation.
* prologue-value.h: Fix indentation.
* psymtab.c: Fix indentation.
* python/py-arch.c: Fix indentation.
* python/py-bpevent.c: Fix indentation.
* python/py-event.c: Fix indentation.
* python/py-event.h: Fix indentation.
* python/py-finishbreakpoint.c: Fix indentation.
* python/py-frame.c: Fix indentation.
* python/py-framefilter.c: Fix indentation.
* python/py-inferior.c: Fix indentation.
* python/py-infthread.c: Fix indentation.
* python/py-objfile.c: Fix indentation.
* python/py-prettyprint.c: Fix indentation.
* python/py-registers.c: Fix indentation.
* python/py-signalevent.c: Fix indentation.
* python/py-stopevent.c: Fix indentation.
* python/py-stopevent.h: Fix indentation.
* python/py-threadevent.c: Fix indentation.
* python/py-tui.c: Fix indentation.
* python/py-unwind.c: Fix indentation.
* python/py-value.c: Fix indentation.
* python/py-xmethods.c: Fix indentation.
* python/python-internal.h: Fix indentation.
* python/python.c: Fix indentation.
* ravenscar-thread.c: Fix indentation.
* record-btrace.c: Fix indentation.
* record-full.c: Fix indentation.
* record.c: Fix indentation.
* reggroups.c: Fix indentation.
* regset.h: Fix indentation.
* remote-fileio.c: Fix indentation.
* remote.c: Fix indentation.
* reverse.c: Fix indentation.
* riscv-linux-tdep.c: Fix indentation.
* riscv-ravenscar-thread.c: Fix indentation.
* riscv-tdep.c: Fix indentation.
* rl78-tdep.c: Fix indentation.
* rs6000-aix-tdep.c: Fix indentation.
* rs6000-lynx178-tdep.c: Fix indentation.
* rs6000-nat.c: Fix indentation.
* rs6000-tdep.c: Fix indentation.
* rust-lang.c: Fix indentation.
* rx-tdep.c: Fix indentation.
* s12z-tdep.c: Fix indentation.
* s390-linux-tdep.c: Fix indentation.
* score-tdep.c: Fix indentation.
* ser-base.c: Fix indentation.
* ser-mingw.c: Fix indentation.
* ser-uds.c: Fix indentation.
* ser-unix.c: Fix indentation.
* serial.c: Fix indentation.
* sh-linux-tdep.c: Fix indentation.
* sh-nbsd-tdep.c: Fix indentation.
* sh-tdep.c: Fix indentation.
* skip.c: Fix indentation.
* sol-thread.c: Fix indentation.
* solib-aix.c: Fix indentation.
* solib-darwin.c: Fix indentation.
* solib-frv.c: Fix indentation.
* solib-svr4.c: Fix indentation.
* solib.c: Fix indentation.
* source.c: Fix indentation.
* sparc-linux-tdep.c: Fix indentation.
* sparc-nbsd-tdep.c: Fix indentation.
* sparc-obsd-tdep.c: Fix indentation.
* sparc-ravenscar-thread.c: Fix indentation.
* sparc-tdep.c: Fix indentation.
* sparc64-linux-tdep.c: Fix indentation.
* sparc64-nbsd-tdep.c: Fix indentation.
* sparc64-obsd-tdep.c: Fix indentation.
* sparc64-tdep.c: Fix indentation.
* stabsread.c: Fix indentation.
* stack.c: Fix indentation.
* stap-probe.c: Fix indentation.
* stubs/ia64vms-stub.c: Fix indentation.
* stubs/m32r-stub.c: Fix indentation.
* stubs/m68k-stub.c: Fix indentation.
* stubs/sh-stub.c: Fix indentation.
* stubs/sparc-stub.c: Fix indentation.
* symfile-mem.c: Fix indentation.
* symfile.c: Fix indentation.
* symfile.h: Fix indentation.
* symmisc.c: Fix indentation.
* symtab.c: Fix indentation.
* symtab.h: Fix indentation.
* target-float.c: Fix indentation.
* target.c: Fix indentation.
* target.h: Fix indentation.
* tic6x-tdep.c: Fix indentation.
* tilegx-linux-tdep.c: Fix indentation.
* tilegx-tdep.c: Fix indentation.
* top.c: Fix indentation.
* tracefile-tfile.c: Fix indentation.
* tracepoint.c: Fix indentation.
* tui/tui-disasm.c: Fix indentation.
* tui/tui-io.c: Fix indentation.
* tui/tui-regs.c: Fix indentation.
* tui/tui-stack.c: Fix indentation.
* tui/tui-win.c: Fix indentation.
* tui/tui-winsource.c: Fix indentation.
* tui/tui.c: Fix indentation.
* typeprint.c: Fix indentation.
* ui-out.h: Fix indentation.
* unittests/copy_bitwise-selftests.c: Fix indentation.
* unittests/memory-map-selftests.c: Fix indentation.
* utils.c: Fix indentation.
* v850-tdep.c: Fix indentation.
* valarith.c: Fix indentation.
* valops.c: Fix indentation.
* valprint.c: Fix indentation.
* valprint.h: Fix indentation.
* value.c: Fix indentation.
* value.h: Fix indentation.
* varobj.c: Fix indentation.
* vax-tdep.c: Fix indentation.
* windows-nat.c: Fix indentation.
* windows-tdep.c: Fix indentation.
* xcoffread.c: Fix indentation.
* xml-syscall.c: Fix indentation.
* xml-tdesc.c: Fix indentation.
* xstormy16-tdep.c: Fix indentation.
* xtensa-config.c: Fix indentation.
* xtensa-linux-nat.c: Fix indentation.
* xtensa-linux-tdep.c: Fix indentation.
* xtensa-tdep.c: Fix indentation.
gdbserver/ChangeLog:
* ax.cc: Fix indentation.
* dll.cc: Fix indentation.
* inferiors.h: Fix indentation.
* linux-low.cc: Fix indentation.
* linux-nios2-low.cc: Fix indentation.
* linux-ppc-ipa.cc: Fix indentation.
* linux-ppc-low.cc: Fix indentation.
* linux-x86-low.cc: Fix indentation.
* linux-xtensa-low.cc: Fix indentation.
* regcache.cc: Fix indentation.
* server.cc: Fix indentation.
* tracepoint.cc: Fix indentation.
gdbsupport/ChangeLog:
* common-exceptions.h: Fix indentation.
* event-loop.cc: Fix indentation.
* fileio.cc: Fix indentation.
* filestuff.cc: Fix indentation.
* gdb-dlfcn.cc: Fix indentation.
* gdb_string_view.h: Fix indentation.
* job-control.cc: Fix indentation.
* signals.cc: Fix indentation.
Change-Id: I4bad7ae6be0fbe14168b8ebafb98ffe14964a695
|
|
* cli/cli-cmds.c (_initialize_cli_cmds): Fix alias command help.
|
|
I noticed a couple of spots where the "disassemble" could style its
output, but currently does not. This patch adds styling to the
function name at the start of the disassembly, and any addresses
printed there.
gdb/ChangeLog
2020-10-08 Tom Tromey <tom@tromey.com>
* cli/cli-cmds.c (print_disassembly): Style function name and
addresses. Add _() wrappers.
gdb/testsuite/ChangeLog
2020-10-08 Tom Tromey <tom@tromey.com>
* gdb.base/style.exp: Check that "main"'s name is styled.
|
