The cmd_list_element::doc variable must be non-nullptr, otherwise, in
`help_cmd` (cli/cli-decode.c), we will trigger an assert when we run
one of these lines:
gdb_puts (c->doc, stream);
or,
gdb_puts (alias->doc, stream);
as gdb_puts requires that the first argument (the doc string) be
non-nullptr.
Better, I think, to assert when the cmd_list_element is created,
rather than catching an assert later when 'help CMD' is used.
I only ran into this case when messing with the Python API command
creation code, I accidentally created a command with a nullptr doc
string, and only found out when I ran 'help CMD' and got an
assertion.
While I'm adding this assertion, I figure I should also assert that
the command name is not nullptr too. Looking through cli-decode.c,
there seems to be plenty of places where we assume a non-nullptr name.
Built and tested on x86-64 GNU/Linux with an all-targets build; I
don't see any regressions, so (I hope) there are no commands that
currently violate this assertion.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
print_doc_line uses a static buffer and manually manages memory. I
think neither of these is really needed, so this patch rewrites the
function to use std::string. The new implementation tries to avoid
copying when possible.
Regression tested on x86-64 Fedora 40.
Reviewed-By: Keith Seitz <keiths@redhat.com>
This updates the copyright headers to include 2025. I did this by
running gdb/copyright.py and then manually modifying a few files as
noted by the script.
Approved-By: Eli Zaretskii <eliz@gnu.org>
Consider this backtrace within GDB:
#0 notify_breakpoint_modified (b=0x57d31d0) at ../../src/gdb/breakpoint.c:1083
#1 0x00000000005b6406 in breakpoint_set_commands (b=0x57d31d0, commands=...) at ../../src/gdb/breakpoint.c:1523
#2 0x00000000005c8c63 in update_dprintf_command_list (b=0x57d31d0) at ../../src/gdb/breakpoint.c:8641
#3 0x00000000005d3c4e in dprintf_breakpoint::re_set (this=0x57d31d0) at ../../src/gdb/breakpoint.c:12476
#4 0x00000000005d6347 in breakpoint_re_set () at ../../src/gdb/breakpoint.c:13298
Whenever breakpoint_re_set is called we re-build the commands that the
dprintf b/p will execute and store these into the breakpoint. The
commands are re-built in update_dprintf_command_list and stored into
the breakpoint object in breakpoint_set_commands.
Now sometimes these commands can change, dprintf_breakpoint::re_set
explains one case where this can occur, and I'm sure there must be
others. But in most cases the commands we recalculate will not
change. This means that the breakpoint modified event which is
emitted from breakpoint_set_commands is redundant.
This commit aims to eliminate the redundant breakpoint modified events
for dprintf breakpoints. This is done by adding a commands_equal call
to the start of breakpoint_set_commands.
The commands_equal function is a new function which compares two
command_line objects and returns true if they are identical. Using
this function we can check if the new commands passed to
breakpoint_set_commands are identical to the breakpoint's existing
commands. If the new commands are equal then we don't need to change
anything on the new breakpoint, and the breakpoint modified event can
be skipped.
The test for this commit stops at a dlopen() call in the inferior,
sets up a dprintf breakpoint, then uses 'next' to step over the
dlopen() call. When the library loads GDB call breakpoint_re_set,
which calls dprintf_breakpoint::re_set. But in this case we don't
expect the calculated command string to change, so we don't expect to
see the breakpoint modified event.
GDB's compile subsystem is deeply tied to GDB's ability to understand
DWARF. A future patch will add the option to disable DWARF at configure
time, but for that to work, the compile subsystem will need to be
entirely disabled as well, so this patch adds that possibility.
I also think there is motive for a security conscious user to disable
compile for it's own sake. Considering that the code is quite
unmaintained, and depends on an equally unmaintained gcc plugin, there
is a case to be made that this is an unnecessary increase in the attack
surface if a user knows they won't use the subsystem. Additionally, this
can make compilation slightly faster and the final binary is around 3Mb
smaller. But these are all secondary to the main goal of being able to
disable dwarf at configure time.
To be able to achieve optional compilation, some of the code that
interfaces with compile had to be changed. All parts that directly
called compile things have been wrapped by ifdefs checking for compile
support. The file compile/compile.c has been setup in a similar way to
how python's and guile's main file has been setup, still being compiled
but only for with placeholder command.
Finally, to avoid several new errors, a new TCL proc was introduced to
gdb.exp, allow_compile_tests, which checks if the "compile" command is
recognized before the inferior is started and otherwise skips the compile
tests. All tests in the gdb.compile subfolder have been updated to use
that, and the test gdb.base/filename-completion also uses this. The proc
skip_compile_feature_tests to recognize when the subsystem has been
disabled at compile time.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
Currently GDB's source cache doesn't track whether the entries within
the cache are styled or not. This is pretty much fine, the assumption
is that any time we are fetching source code, we do so in order to
print it to the terminal, so where possible we always want styling
applied, and if styling is not applied, then it is because that file
cannot be styled for some reason.
Changes to 'set style enabled' cause the source cache to be flushed,
so future calls to fetch source code will regenerate the cache entries
with styling enabled or not as appropriate.
But this all assumes that styling is either on or off, and that
switching between these two states isn't done very often.
However, the Python API allows for individual commands to be executed
with styling turned off via gdb.execute(). See commit:
commit e5348a7ab3
Date: Thu Feb 13 15:39:31 2025 +0000
gdb/python: new styling argument to gdb.execute
Currently the source cache doesn't handle this case. Consider this:
(gdb) list main
... snip, styled source code displayed here ...
(gdb) python gdb.execute("list main", True, False, False)
... snip, styled source code is still shown here ...
In the second case, the final `False` passed to gdb.execute() is
asking for unstyled output.
The problem is that, `get_source_lines` calls `ensure` to prime the
cache for the file in question, then `extract_lines` just pulls the
lines of interest from the cached contents.
In `ensure`, if there is a cache entry for the desired filename, then
that is considered good enough. There is no consideration about
whether the cache entry is styled or not.
This commit aims to fix this, after this commit, the `ensure` function
will make sure that the cache entry used by `get_source_lines` is
styled correctly.
I think there are two approaches I could take:
1. Allow multiple cache entries for a single file, a styled, and
non-styled entry. The `ensure` function would then place the
correct cache entry into the last position so that
`get_source_lines` would use the correct entry, or
2. Have `ensure` recalculate entries if the required styling mode is
different to the styling mode of the current entry.
Approach #1 is better if we are rapidly switching between styling
modes, while #2 might be better if we want to keep more files in the
cache and we only rarely switch styling modes.
In the end I chose approach #2, but the good thing is that the changes
are all contained within the `ensure` function. If in the future we
wanted to change to strategy #1, this could be done transparently to
the rest of GDB.
So after this commit, the `ensure` function checks if styling is
currently possible or not. If it is not, and the current entry is
styled, then the current entry only is dropped from the cache, and a
new, unstyled entry is created. Likewise, if the current entry is
non-styled, but styling is required, we drop one entry and
recalculate.
With this change in place, I have updated set_style_enabled (in
cli/cli-style.c) so the source cache is no longer flushed when the
style settings are changed, the source cache will automatically handle
changes to the style settings now.
This problem was discovered in PR gdb/32676.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32676
Approved-By: Tom Tromey <tom@tromey.com>
Currently, gdb.execute emits styled output when the command is sending
its output to GDB's stdout, and produces unstyled output when the
output is going to a string.
But it is not unreasonable that a user might wish to capture styled
output from a gdb.execute call, for example, the user might want to
display the styled output are part of some larger UI output block.
At the same time, I don't think it makes sense to always produce
styled output when capturing the output in a string; if what the user
wants is to parse the output, then the style escape sequences make
this far harder.
I propose that gdb.execute gain a new argument 'styling'. When False
we would always produce unstyled output, and when True we would
produce styled output if styling is not disabled by some other means.
For example, if GDB's 'set style enabled' is off, then I think
gdb.execute() should respect that. My assumption here is that
gdb.execute() might be executed by some extension. If the extension
thinks "styled output world work here", but the user hates styled
output, and has turned it off, then the extension should not be
forcing styled output on the user.
I chose 'styling' instead of 'styled' as the Python argument name
because we already use 'styling' in gdb.Value.format_string, and we
don't use 'styled' anywhere else. This is only a little bit of
consistency, but I still think it's a good thing.
The default for 'styling' will change depending on where the output is
going. When gdb.execute is sending the output to GDB's stdout then
the default for 'styling' is True. When the output is going to a
string, then the default for 'styling' will be False. Not only does
this match the existing behaviour, but I think this makes sense. By
default we assume that output captured in a string is going to be
parsed, and therefore styling markup is unhelpful, while output going
to stdout should receive styling.
This fixes part of the problem described in PR gdb/32676. That bug
tries to capture styled source listing in a string, which wasn't
previously possible.
There are some additional issues with capturing source code; GDB
caches the source code in the source code cache. However, GDB doesn't
check if the cached content is styled or not. As a consequence, if
the first time the source of a file is shown it is unstyled, then the
cached will hold the unstyled source code, and future requests will
return that unstyled source. I'll address this issue in a separate
patch.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32676
Approved-By: Tom Tromey <tom@tromey.com>
The cli_styling variable is controlled by 'set style enabled on|off'
user setting, and is currently globally visible.
In a couple of places we access this variable directly, though in
ui-file.c the accesses are all performed through term_cli_styling(),
which is a function that wraps checking cli_styling along with a check
that GDB's terminal supports styling.
In a future commit, I'd plan to add a new parameter to gdb.execute()
which will allow styling to be temporarily suppressed. In an earlier
proposal, I made gdb.execute() disable styling by changing the value
of cli_styling, however, this approach has a problem.
If gdb.execute() is used to run 'show style enabled', the changing
cli_styling will change what is printed. Similarly, if gdb.execute()
is used to execute 'set style enabled on|off' then having
gdb.execute() save and restore the value of cli_styling will undo the
adjustment from 'set style enabled ...'.
So what I plan to do in the future, is add a new control flag which
can be used to temporarily disable styling.
To make this new control variable easier to add, lets force everyone
to call term_cli_styling() to check if styling is enabled or not. To
force everyone to use term_cli_styling() this commit makes cli_styling
static within gdb/cli/cli-style.c.
Approved-By: Tom Tromey <tom@tromey.com>
We currently check the TERM environment variable any time we call one
of the ui_file::can_emit_style_escape() functions. This seems
excessive.
During GDB's startup we also check for the NO_COLOR environment
variable and disable styling if this is set.
I propose that we combine these two checks, and perform them just once
during startup (as the current NO_COLOR check is currently done). As
with the NO_COLOR check, if the TERM variable is set to "dumb"
indicating that styling is not supported then we should just set
cli_styling to false.
This does mean that the user can then 'set style enabled on', even for
a dumb terminal, which was not possible previously. Before this
commit the "dumb" terminal check was separate and would prevent
styling even if 'set style enabled on' was in effect.
Of course, trying to turn on styling in a dumb terminal might not give
the results that a user hope for. And so, I have implemented a check
in `set_style_enabled`, so in a dumb terminal a user will see this:
(gdb) set style enabled on
warning: The current terminal doesn't support styling. Styled output might not appear as expected.
After which GDB will try to emit styling. We could, potentially,
prevent styling being enabled instead of emitting a warning, but I'm
inclined to let the user turn on styling if they really want to.
Approved-By: Kevin Buettner <kevinb@redhat.com>
Acked-By: Tom Tromey <tom@tromey.com>
The help text for 'set/show style disassembler enable' was output of
date. It talks about GDB requiring the Python Pygments library, but
for many common architectures this is no longer the case, libopcode is
used for styling.
The Python Pygments library is still used as a fallback for those
architectures that libopcode doesn't currently style.
I've updated the help text to try and explain all this. The manual
was already updated.
Approved-By: Eli Zaretskii <eliz@gnu.org>
color_option_def was added in commit 6447969d0 ("Add an option with a
color type."), but not used.
The color_option_def constructor passes the wrong number of arguments
to the option_def constructor. Since color_option_def is a template and
never actually instantiated, GCC does not fail to compile this. clang
generates an error (see below).
This passes nullptr to the extra_literals_ option_def ctor argument,
which matches what filename_option_def above it does.
clang's generated error:
../../gdb/cli/cli-option.h:343:7: error: no matching constructor for initialization of 'option_def'
: option_def (long_option_, var_color,
^ ~~~~~~~~~~~~~~~~~~~~~~~~
../../gdb/cli/cli-option.h:50:13: note: candidate constructor not viable: requires 8 arguments, but 7 were provided
constexpr option_def (const char *name_,
^
../../gdb/cli/cli-option.h:37:8: note: candidate constructor (the implicit copy constructor) not viable: requires 1 argument, but 7 were provided
struct option_def
^
../../gdb/cli/cli-option.h:37:8: note: candidate constructor (the implicit move constructor) not viable: requires 1 argument, but 7 were provided
Approved-By: Tom de Vries <tdevries@suse.de>
With an x86_64-w64-mingw32 targeted cross-build on x86_64-linux, I run into:
...
gdb/cli/cli-decode.c: \
In function 'ui_file_style::color parse_cli_var_color(const char**)':
gdb/cli/cli-decode.c:2917:41: error: expected ')' before 'SCNx8'
int parsed_args = sscanf (*args, "#%2" SCNx8 "%2" SCNx8 "%2" SCNx8 "%n",
...
Apparantly, the definition of SCNx8 is missing in inttypes.h.
Rewrite the sscanf call to use SCNx32, which is available.
Tested by:
- completing aforementioned cross-build, and
- build & test on x86_64-linux.
Suggested-By: Tom Tromey <tom@tromey.com>
Approved-By: Tom Tromey <tom@tromey.com>
cmd_show_list is a bit funny because it shows partial command names --
for a command like "show abc xyz", it will only show "abc xyz".
Nevertheless, I think it makes some sense to highlight these with the
command style. That is what this patch does.
This changes the help command to use the new command style when
displaying text like:
List of "catch" subcommands:
As a side effect, this mildly -- but not hugely -- cleans up some i18n
issues in help_list. The header comment for that function is also
changed to the gdb style.
Finally, this function used to print something like:
Type "help catch" followed by catch subcommand name for full documentation.
The second "catch" here seems redundant to me, so this patch removes
it.
I happened to notice that "help add-inferior" said:
-execFILENAME
FILENAME is the file name of the executable to use as the
main program.
This is missing a space after "-exec". This patch fixes the bug.
If ok'd on time I plan to check this in to the gdb-16 branch as well.
Approved-by: Kevin Buettner <kevinb@redhat.com>
I found a few filename-related "show" commands that do not use the
filename style when displaying the file. This patch fixes the
oversight.
Approved-By: Andrew Burgess <aburgess@redhat.com>
Colors can be specified as "none" for terminal's default color, as a name of
one of the eight standard colors of ISO/IEC 6429 "black", "red", "green", etc.,
as an RGB hexadecimal tripplet #RRGGBB for 24-bit TrueColor, or as an
integer from 0 to 255. Integers 0 to 7 are the synonyms for the standard
colors. Integers 8-15 are used for the so-called bright colors from the
aixterm extended 16-color palette. Integers 16-255 are the indexes into xterm
extended 256-color palette (usually 6x6x6 cube plus gray ramp). In
general, 256-color palette is terminal dependent and sometimes can be
changed with OSC 4 sequences, e.g. "\033]4;1;rgb:00/FF/00\033\\".
It is the responsibility of the user to verify that the terminal supports
the specified colors.
PATCH v5 changes: documentation fixed.
PATCH v6 changes: documentation fixed.
PATCH v7 changes: rebase onto master and fixes after review.
PATCH v8 changes: fixes after review.
This patch is the result of running check-include-guards.py on the
current tree. Running it a second time causes no changes.
Reviewed-By: Tom de Vries <tdevries@suse.de>
Currently the "title" style is only used when printing command names.
The "title" name itself is probably a misnomer, but meanwhile this
patch changes the existing uses to instead use the new "command" style
for consistency.
The "title" style is not removed; see the next patch.
Reviewed-By: Keith Seitz <keiths@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
This adds a new "command" style that is used when styling the name of
a gdb command.
Note that not every instance of a command name that is output by gdb
is changed here. There is currently no way to style error() strings,
and there is no way to mark up command help strings.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31747
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Keith Seitz <keiths@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
We have gdb::handle_eintr, which allows us to rewrite:
...
ssize_t ret;
do
{
errno = 0;
ret = ::write (pipe[1], "+", 1);
}
while (ret == -1 && errno == EINTR);
...
into:
...
ssize_t ret = gdb::handle_eintr (-1, ::write, pipe[1], "+", 1);
...
However, the call to write got a bit mangled, requiring effort to decode it
back to its original form.
Instead, add a new function gdb::write that allows us to write:
...
ssize_t ret = gdb::write (pipe[1], "+", 1);
...
Likewise for waitpid, read and close.
Tested on x86_64-linux.
When disassembling function symbols in C++ code, if GDB is asked to
disassemble a function by name then the function name in the header
line can be demangled by turning on `set print asm-demangle on`, e.g.:
(gdb) disassemble foo_type::some_function
Dump of assembler code for function _ZN8foo_type13some_functionE7my_type:
0x0000000000401142 <+0>: push %rbp
... etc ...
End of assembler dump.
(gdb) set print asm-demangle on
(gdb) disassemble foo_type::some_function
Dump of assembler code for function foo_type::some_function(my_type):
0x0000000000401142 <+0>: push %rbp
... etc ... │
End of assembler dump. │
However, if GDB is disassembling the current function, then this
demangling doesn't work, e.g.:
(gdb) break foo_type::some_function
Breakpoint 1 at 0x401152: file mangle.cc, line 16.
(gdb) run
Starting program: /tmp/mangle
Breakpoint 1, foo_type::some_function (this=0x7fffffffa597, obj=...) at mangle.cc:16
16 obj.update ();
(gdb) disassemble
Dump of assembler code for function _ZN8foo_type13some_functionE7my_type:
0x0000000000401142 <+0>: push %rbp
... etc ...
End of assembler dump.
(gdb) set print asm-demangle on
(gdb) disassemble
Dump of assembler code for function _ZN8foo_type13some_functionE7my_type:
0x0000000000401142 <+0>: push %rbp
... etc ...
End of assembler dump.
This commit fixes this issue, and extends gdb.cp/disasm-func-name.exp,
which was already testing the first case (disassemble by name) to also
cover disassembling the current function.
Approved-By: Tom Tromey <tom@tromey.com>
When building a help string, it's possible that the resulting options
will go over 80 columns. This patch changes this code to add line
wrapping where needed.
This can most be seen by looking "help bt" and in particular the
"-frame-info" help text.
This patch ensures that all ordinary help strings are wrapped at 80
columns. For the most part this consists of changing code like this
(note the embedded \n and the trailing backslash without a newline):
-Manage the space-separated list of debuginfod server URLs that GDB will query \
-when missing debuginfo, executables or source files.\nThe default value is \
-copied from the DEBUGINFOD_URLS environment variable."),
... to end each line with \n\, like:
+Manage the space-separated list of debuginfod server URLs that GDB will\n\
+query when missing debuginfo, executables or source files.\n\
+The default value is copied from the DEBUGINFOD_URLS environment variable."),
Approved-By: Eli Zaretskii <eliz@gnu.org>
This commit was inspired by this mailing list post:
https://inbox.sourceware.org/gdb-patches/osmtfvf5xe3yx4n7oirukidym4cik7lehhy4re5mxpset2qgwt@6qlboxhqiwgm
When reviewing that patch, the first thing I wanted to do was add some
tests for the 'edit' command because, as far as I can tell, there are
no real tests right now.
The approach I've taken for testing is to override the EDITOR
environment variable, setting this to just 'echo'. Now when the
'edit' command is run, instead of entering an interactive editor, the
shell instead echos back the arguments that GDB is trying to pass to
the editor. The output might look like this:
(gdb) edit
+22 /tmp/gdb/testsuite/gdb.base/edit-cmd.c
(gdb)
We can then test this like any other normal command. I then wrote
some basic tests covering a few situations like, using 'edit' before
the inferior is started. Using 'edit' without any arguments, and
using 'edit' with a line number argument.
There are plenty of cases that are still not tested, for example, the
test program only has a single source file for example. But we can
always add more tests later.
I then used these tests to validate the fix proposed in the above
patch.
The patch above does indeed fix some cases, specifically, when GDB
stops at a location (e.g. a breakpoint location) and then the 'edit'
command without any arguments is fixed. But using the 'list' command
to show some other location, and then 'edit' to edit the just listed
location broken before and after the above patch.
I am instead proposing this alternative patch which I think fixes more
cases. When GDB stops at a location then 'edit' with no arguments
should correctly edit the current line. And using 'list XX' to list a
specific location, followed by 'edit' should also now edit the just
listed location.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17669
Co-Authored-By: Lluís Batlle i Rossell <viric@viric.name>
Approved-By: Tom Tromey <tom@tromey.com>
This commit adds support for filename options to GDB's option
sub-system (see cli/cli-option.{c,h}).
The new filename options support quoted and escaped filenames, and tab
completion is fully supported.
This commit adds the new option, and adds these options to the
'maintenance test-options' command as '-filename', along with some
tests that exercise this new option.
I've split the -filename testing into two. In gdb.base/options.exp we
use the -filename option with some arbitrary strings. This tests that
GDB can correctly extract the value from a filename option, and that
GDB can complete other options after a filename option. However,
these tests don't actually pass real filenames, nor do they test
filename completion.
In gdb.base/filename-completion.exp I have added some tests that test
the -filename option with real filenames, and exercise filename tab
completion.
This commit doesn't include any real uses of the new filename options,
that will come in the next commit.
When building gdb with -O2 -fsanitize=thread and running test-case
gdb.base/bg-exec-sigint-bp-cond.exp, I run into:
...
(gdb) c&^M
Continuing.^M
(gdb) Quit^M
(gdb) quit_count=1
^M
Breakpoint 2, foo () at bg-exec-sigint-bp-cond.c:23^M
23 return 0;^M
FAIL: $exp: no force memory write: \
SIGINT does not interrupt background execution
...
What happens is that:
- the breakpoint hits
- while evaluating the condition of the breakpoint,
$_shell("kill -INT <pid-of-gdb>") is called, handled by run_under_shell
- in run_under_shell, a vfork is issued
- in the vfork child, execl executes the kill command
- in the vfork parent, waitpid is called to wait for the result of the kill
command
- waitpid returns -1 with errno set to EINTR
- run_under_shell doesn't check the result of waitpid, and returns the
value of local variable status. Since waitpid returned -1, status was
not assigned a value, so it's uninitialized, and happens to be
non-zero
- the breakpoint condition evaluates to true, because
$_shell("kill -INT <pid-of-gdb>") != 0
- the breakpoint triggers a stop, which the test-case doesn't expect.
Fix this by using gdb::handle_eintr to call waitpid in run_under_shell.
Also handle the case that waitpid returns an error other than EINTR, using
perror_with_name.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR gdb/30695
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30695
I searched for spots using ".reset (new ...)" and replaced most of
these with std::make_unique. I think this is a bit cleaner and more
idiomatic.
Regression tested on x86-64 Fedora 40.
Reviewed-By: Klaus Gerlicher<klaus.gerlicher@intel.com>
Add two more separators in spellcheck.sh: colon and comma.
Doing so triggers the "inbetween->between" rule, which gives an incorrect
result. Override this with "inbetween->between, in between, in-between" [1],
in a new file gdb/contrib/common-misspellings.txt.
Fix the following common misspellings:
...
everytime -> every time
sucess -> success
thru -> through
transfered -> transferred
inbetween -> between, in between, in-between
...
Verified with spellcheck.sh. Tested on x86_64-linux.
[1] https://www.grammarly.com/blog/commonly-confused-words/in-between-or-inbetween/
While looking at the recent line number styling commit I noticed a few
places where we could add more file name styling. So lets do that.
Approved-By: Tom Tromey <tom@tromey.com>
This patch adds separate styling for line numbers. That is, whenever
gdb prints a source line number, it uses this style.
v2 includes a change to ensure that %ps works in query.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-by: Keith Seitz <keiths@redhat.com>
Some of the gdb and testsuite files double include some headers. While
all headers use include guards, it helps a bit keeping the code base
tidy.
No functional change.
Approved-by: Kevin Buettner <kevinb@redhat.com>
This commit moves the printing of the 'complete' command results out
of the 'complete_command' function. The printing is now done in a new
member function 'completion_result::print_matches'. At this point,
this is entirely a refactor.
The motivation for this refactor is how 'complete' should print the
completion of filename arguments. In some cases the filename results
need to have escaping added to the output. This escaping needs to be
done immediately prior to printing the result as adding too early will
result in multiple 'complete' results potentially being sorted
incorrectly. See the subsequent commits for more details.
There should be no user visible changes after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
Following on from the previous commit, this commit marks the old
unquoted filename completion related functions as deprecated.
The aim of doing this is to make it more obvious to someone adding a
new command that they should not be using the older unquoted style
filename argument handling.
I split this change from the previous to make for an easier review.
This commit touches more files, but is _just_ function renaming.
Check out gdb/completer.{c,h} for what has been renamed. All the
other files have just been updated to use the new names.
There should be no user visible changes after this commit.
Make the current program space reference bubble up one level.
Change-Id: I6ba6dc4a2cb188720cbb61b84ab5c954aac105c6
Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Make the current program space reference bubble up one level.
Change-Id: I19c4fc2ca955f9c828ef426a077b43983865697b
Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Make the current program space reference bubble up one level.
Change-Id: I692554474d17e4f4708fd8ad662bf6c0bb964726
Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Remove some includes reported as unused by clangd. Add some includes in
other files that were previously relying on the transitive include.
Change-Id: Ibdd0a998b04d21362a20d0ca8e5267e21e2e133e
This patch removes gdb_stdtargerr. There doesn't seem to be a need
for this -- it is always the same as stdtarg, and (I believe) has been
for many years.
Approved-By: Andrew Burgess <aburgess@redhat.com>
Currently, when a user tries to list the current location, there are 2
different error messages that can happen, either:
(gdb) list .
No symbol table is loaded. Use the "file" command.
or
(gdb) list .
No debug information available to print source lines.
The difference here is if gdb can find any symtabs at all or not, which
is not something too important for end-users - and isn't informative at
all. This commit changes it so that the error always says that there
isn't debug information available, with these two variants:
(gdb) list .
Insufficient debug info for showing source lines at current PC (0x55555555511d).
or
(gdb) list .
Insufficient debug info for showing source lines at default location.
The difference now is if the inferior has started already, which is
controlled by the user and may be useful.
Unfortunately, it isn't as easy to differentiate if the symtab found for
other list parameters is correct, so other invocations, such as "list +"
still retain their original error message.
Co-Authored-By: Simon Marchi <simark@simark.ca>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>
Most files including gdbcmd.h currently rely on it to access things
actually declared in cli/cli-cmds.h (setlist, showlist, etc). To make
things easy, replace all includes of gdbcmd.h with includes of
cli/cli-cmds.h. This might lead to some unused includes of
cli/cli-cmds.h, but it's harmless, and much faster than going through
the 170 or so files by hand.
Change-Id: I11f884d4d616c12c05f395c98bbc2892950fb00f
Approved-By: Tom Tromey <tom@tromey.com>
Move some declarations related to the "quit" machinery from defs.h to
event-top.h. Most of the definitions associated to these declarations
are in event-top.c. The exceptions are `quit()` and `maybe_quit()`,
that are defined in utils.c. For consistency, move these two
definitions to event-top.c.
Include "event-top.h" in many files that use these things.
Change-Id: I6594f6df9047a9a480e7b9934275d186afb14378
Approved-By: Tom Tromey <tom@tromey.com>
Move it out of defs.h, adjust the includes here and there.
Change-Id: I11901fdce55d54f5e51723e123cef154cfb1bbc5
Approved-By: John Baldwin <jhb@FreeBSD.org>
Now that defs.h, server.h and common-defs.h are included via the
`-include` option, it is no longer necessary for source files to include
them. Remove all the inclusions of these files I could find. Update
the generation scripts where relevant.
Change-Id: Ia026cff269c1b7ae7386dd3619bc9bb6a5332837
Approved-By: Pedro Alves <pedro@palves.net>
Currently gdb.parameter doesn't raise an exception if an
ambiguous name is used, it instead returns the value of the
last partly matching parameter:
```
(gdb) show print sym
Ambiguous show print command "sym": symbol, symbol-filename, symbol-loading.
(gdb) show print symbol-loading
Printing of symbol loading messages is "full".
(gdb) py print(gdb.parameter("print sym"))
full
```
It's because lookup_cmd_composition_1 tries to detect
ambigous names by checking the return value of find_cmd
for CMD_LIST_AMBIGUOUS, which never happens, since only
lookup_cmd_1 returns CMD_LIST_AMBIGUOUS.
Instead the nfound argument contains the number of found
matches.
By using it instead, and by setting *CMD to the special value
CMD_LIST_AMBIGUOUS in this case, gdbpy_parameter can now show
the appropriate error message:
```
(gdb) py print(gdb.parameter("print sym"))
Traceback (most recent call last):
File "<string>", line 1, in <module>
RuntimeError: Parameter `print sym' is ambiguous.
Error while executing Python code.
(gdb) py print(gdb.parameter("print symbol"))
True
(gdb) py print(gdb.parameter("print symbol-"))
Traceback (most recent call last):
File "<string>", line 1, in <module>
RuntimeError: Parameter `print symbol-' is ambiguous.
Error while executing Python code.
(gdb) py print(gdb.parameter("print symbol-load"))
full
```
Since the document command also uses lookup_cmd_composition, it needed
to check for CMD_LIST_AMBIGUOUS as well, so it now also shows an
"Ambiguous command" error message in this case.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=14639
Approved-By: Tom Tromey <tom@tromey.com>
