| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Commit f14bbacae00d ("gdb/guile: remove support for Guile < 2.2")
removed some code supporting Guile 2.0. This patch removes more bits
related to Guile 2.0, and adds a NEWS entry.
* Remove Guile 2.0 mention from the doc.
* Remove HAVE_GUILE_MANUAL_FINALIZATION, assume it is always true.
* Remove guile-2.0 from the versions automatically tried by configure.
* Remove check for scm_new_smob (HAVE_SCM_NEW_SMOB), assume it is
always true.
* Remove hack to fill ac_cv_guild_program_name when the .pc file
wouldn't specify it.
Tested by rebuilding against guile-3.0 and guile-2.2.
Change-Id: I2e89bcd4a4429262f4c3a1c74b275768e60f0cb0
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
I propose to remove the code in guile/scm-ports.c supporting Guile <
2.2. The rationale is:
- The code within USING_GUILE_BEFORE_2_2 amounts to about half of the
file, it makes it much more complicated than it would be otherwise.
I'm trying to investigate PR 29825 [1] and this is getting in the
way.
- Guile 2.2, which would now be the baseline for what we require, is
now 8 years old. Guile 2.2 is legacy (the current stable branch is
3.0), but it is still actively packaged [2][3].
- The Guile support code doesn't receive as much contribution, testing
and love as the Python support code, for instance. We don't have
cycles to spare to support an obsolete version of Guile.
This patch removes the USING_GUILE_BEFORE_2_2 define and all the
portions of code within `#if USING_GUILE_BEFORE_2_2`.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=29825
[2] https://packages.debian.org/sid/guile-2.2-dev
[3] https://archlinux.org/packages/extra/x86_64/guile2.2/
Change-Id: I926e79cde9835567eb3b7e3d22db402c841b79d7
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
|
|
Commit 7028626eff3 (gdb: make command classes be bitmaps) broke the
build, causing the compiler to issue an error message about the global
scm-cmd.c:command_classes being redefined as a different type.
Renaming the global fix the problem.
|
|
Currently, there is no way for a new user to have an idea of common
useful commands and behaviors from the GDB interface itself, without
checking the example session in the documentation. This command class
aims to close that gap by providing a set of quickstart commands that
allows for any simple debug session to happen without anything too
egregious missing.
The set of commands was chosen somewhat arbitrarily, based on what I
used or missed the most. The one overarching important thing, however,
is that the list is kept short, so as to not overwhelm new users. This
is confirmed by the newly introduced selftest, essential_command_count,
which ensures there are 20 or fewer essential commands.
Here's the reasoning for some of the choices:
* The command "start" was picked over "run" because combining it with
"continue" achieves the same effect, and I prefer it over needing to set
a breakpoint on main to stop at the start of the inferior.
* The command "ptype" is chosen because I believe it is important to
provide a way for the user to check a variable's type from inside GDB,
and ptype is a more complete command than the alternative, "whatis".
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I noticed my IDE (VSCode) starting to automatically trim trailing
whitespaces on save, despite the setting for it being disabled. I
realized that this is because the .editorconfig file now has
trim_trailing_whitespace = true
for many file types. If we have this EditorConfig setting forcing
editors to trim trailing whitespaces, I think it would make sense to
clean up trailing whitespaces from our files. Otherwise, people will
always get spurious whitespace changes when editing these files.
I did a mass cleanup using this command:
$ find gdb gdbserver gdbsupport -type f \( \
-name "*.c" -o \
-name "*.h" -o \
-name "*.cc" -o \
-name "*.texi" -o \
-name "*.exp" -o \
-name "*.tcl" -o \
-name "*.py" -o \
-name "*.s" -o \
-name "*.S" -o \
-name "*.asm" -o \
-name "*.awk" -o \
-name "*.ac" -o \
-name "Makefile*" -o \
-name "*.sh" -o \
-name "*.adb" -o \
-name "*.ads" -o \
-name "*.d" -o \
-name "*.go" -o \
-name "*.F90" -o \
-name "*.f90" \
\) -exec sed -ri 's/[ \t]+$//' {} +
I then did an autotools regen, because we don't actually want to change
the Makefile and Makefile.in files that are generated.
Change-Id: I6f91b83e3b8c4dc7d5d51a2ebf60706120efe691
|
|
Change-Id: I293b655e8753fc650f3ec10bb4e34a9632d8e377
Approved-by: Kevin Buettner <kevinb@redhat.com>
|
|
Change-Id: I6eef5db4ae55f3eb0415768207ae3c26b305f773
Approved-by: Kevin Buettner <kevinb@redhat.com>
|
|
Change-Id: I2069be1a6d7c3250cf330574c941bf851c89bab4
Approved-by: Kevin Buettner <kevinb@redhat.com>
|
|
Same rationale as the previous patches.
Change-Id: I4673cedaa902c9a327d24d73508b18cf60a2cd02
Approved-By: Tom Tromey <tom@tromey.com>
|
|
PR ada/33217 points out that gdb incorrectly calls the <ctype.h>
functions. In particular, gdb feels free to pass a 'char' like:
char *str = ...;
... isdigit (*str)
This is incorrect as isdigit only accepts EOF and values that can be
represented as 'unsigned char' -- that is, a cast is needed here to
avoid undefined behavior when 'char' is signed and a character in the
string might be sign-extended. (As an aside, I think this API seems
obviously bad, but unfortunately this is what the standard says, and
some systems check this.)
Rather than adding casts everywhere, this changes all the code in gdb
that uses any <ctype.h> API to instead call the corresponding c-ctype
function.
Now, c-ctype has some limitations compared to <ctype.h>. It works as
if the C locale is in effect, so in theory some non-ASCII characters
may be misclassified. This would only affect a subset of character
sets, though, and in most places I think ASCII is sufficient -- for
example the many places in gdb that check for whitespace.
Furthermore, in practice most users are using UTF-8-based locales,
where these functions aren't really informative for non-ASCII
characters anyway; see the existing workarounds in gdb/c-support.h.
Note that safe-ctype.h cannot be used because it causes conflicts with
readline.h. And, we canot poison the <ctype.h> identifiers as this
provokes errors from some libstdc++ headers.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33217
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
The enum address_class and related fields and methods seem misnamed to
me. Generalize it to "location_class". The enumerators in
address_class are already prefixed with LOC, so the new name seems
logical to me. Rename related fields and methods as well.
Plus, address_class could easily be mistaken for other unrelated things
named "address class" in GDB or DWARF.
Tested by rebuilding.
Change-Id: I0dca3738df412b350715286c608041b08e9b4d82
Approved-by: Kevin Buettner <kevinb@redhat.com>
|
|
This patch changes type::fields to return an array_view of the fields,
then fixes up the fallout.
More cleanups would be possible here (in particular in the field
initialization code) but I haven't done so.
The main motivation for this patch was to make it simpler to iterate
over the fields of a type.
Regression tested on x86-64 Fedora 41.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This patch introduces a new macro, INIT_GDB_FILE. This is used to
replace the current "_initialize_" idiom when introducing a per-file
initialization function. That is, rather than write:
void _initialize_something ();
void
_initialize_something ()
{
...
}
... now you would write:
INIT_GDB_FILE (something)
{
...
}
The macro handles both the declaration and definition of the function.
The point of this approach is that it makes it harder to accidentally
cause an initializer to be omitted; see commit 2711e475 ("Ensure
cooked_index_entry self-tests are run"). Specifically, the regexp now
used by make-init-c seems harder to trick.
New in v2: un-did some erroneous changes made by the script.
The bulk of this patch was written by script.
Regression tested on x86-64 Fedora 41.
|
|
For reference see the previous commit.
Fix a memory leak in gdbscm_parse_command_name when a guile exception
is thrown. To reveal the memory leak I placed the following content
into a file 'leak.scm':
(use-modules (gdb))
(register-command!
(make-command
"break cmd"
#:command-class COMMAND_OBSCURE
#:invoke (lambda (self arg from-tty)
(display "Hello World"))))
Then in GDB:
(gdb) source leak.scm
ERROR: In procedure register-command!:
In procedure gdbscm_register_command_x: Out of range: 'break' is not a prefix command in position 1: "break cmd"
Error while executing Scheme code.
Running this under valgrind reveals a memory leak for 'result' and
'prefix_text' from gdbscm_parse_command_name.
Another leak can be revealed with this input script:
(use-modules (gdb))
(register-command!
(make-command
"unknown-prefix cmd"
#:command-class COMMAND_OBSCURE
#:invoke (lambda (self arg from-tty)
(display "Hello World"))))
This one occurs earlier in gdbscm_parse_command_name, and now only
'result' leaks.
The problem is that, when guile throws an exception then a longjmp is
performed from the function that raise the exception back to the guile
run-time. A consequence of this is that no function local destructors
will be run.
In gdbscm_parse_command_name, this means that the two function locals
`result` and `prefix_text` will not have their destructors run, and
any memory managed by these objects will be leaked.
Fix this by assigning nullptr to these two function locals before
throwing an exception. This will cause the managed memory to be
deallocated.
I could have implemented a fix that made use of Guile's dynwind
mechanism to register a cleanup callback, however, this felt like
overkill. At the point the exception is being thrown we know that we
no longer need the managed memory, so we might as well just free the
memory at that point.
With this fix in place, the two leaks are now fixed in the valgrind
output.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
In gdbpy_parse_command_name (python/py-cmd.c) there is a call to
xmalloc that can easily be replaced with a call to
make_unique_xstrndup, which makes the code easier to read (I think).
In gdbscm_parse_command_name (guile/scm-cmd.c) the same fix can be
applied to remove an identical xmalloc call. And there is an
additional xmalloc call, which can also be replaced with
make_unique_xstrndup in the same way.
The second xmalloc call in gdbscm_parse_command_name was also present
in gdbpy_parse_command_name at one point, but was replaced with a use
of std::string by this commit:
commit 075c55e0cc0a68eeab777027213c2f545618e844
Date: Wed Dec 26 11:05:57 2018 -0700
Remove more calls to xfree from Python
I haven't changed the gdbscm_parse_command_name to use std::string
though, as that doesn't work well with the guile exception model.
Guile exceptions work by performing a longjmp from the function that
raises the exception, back to the guile run-time. The consequence of
this is that destructors are not run. For example, if
gdbscm_parse_command_name calls gdbscm_out_of_range_error, then any
function local objects in gdbscm_parse_command_name will not have
their destructors called.
What this means is that, for the existing `result` and `prefix_text`
locals, any allocated memory managed by these objects will be leaked
if an exception is called. However, fixing this is pretty easy, one
way is to just assign nullptr to these locals before raising the
exception, this would cause the allocated memory to be released.
But for std::string it is harder to ensure that the managed memory has
actually been released. We can call std::string::clear() and then
maybe std::string::shrink_to_fit(), but this is still not guaranteed
to release any managed memory. In fact, I believe the only way to
ensure all managed memory is released, is to call the std::string
destructor.
And so, for functions that can throw a guile exception, it is easier
to just avoid std::string.
As for the memory leak that I identify above; I'll fix that in a
follow on commit.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
A commit I recently pushed:
commit 0b5023cc71d3af8b18e10e6599a3f9381bc15265
Date: Sat Apr 12 09:15:53 2025 +0100
gdb/python/guile: user created prefix commands get help list
can trigger a segfault if a user tries to create nested prefix
commands. For example, this will trigger a crash:
(gdb) python gdb.ParameterPrefix("prefix-1", gdb.COMMAND_NONE)
(gdb) python gdb.ParameterPrefix("prefix-1 prefix-2", gdb.COMMAND_NONE)
Fatal signal: Segmentation fault
... etc ...
If the user adds an actual parameter under 'prefix-1' before creating
'prefix-2', then everything is fine:
(gdb) python gdb.ParameterPrefix("prefix-1", gdb.COMMAND_NONE)
(gdb) python gdb.Parameter('prefix-1 param-1', gdb.COMMAND_NONE, gdb.PARAM_BOOLEAN)
(gdb) python gdb.ParameterPrefix("prefix-1 prefix-2", gdb.COMMAND_NONE)
The mistake in the above patch is in how gdbpy_parse_command_name is
used. The BASE_LIST output argument from this function points to the
list of commands for the prefix, not to the prefix command itself.
So when gdbpy_parse_command_name is called for 'prefix-1 prefix-2',
BASE_LIST points to the list of commands associated with 'prefix-1',
not to the actual 'prefix-1' cmd_list_element.
Back in cmdpy_init, from where gdbpy_parse_command_name was called, I
was walking back from the first entry in BASE_LIST to figure out if
this was a "show" prefix command or not. However, if BASE_LIST is
empty then there is no first item, and this would trigger the
segfault.
The solution it to extend gdbpy_parse_command_name to also return the
prefix cmd_list_element in addition to the existing values. With this
done, and cmdpy_init updated, the segfault is now avoided.
There's a new test that would trigger the crash without the patch.
And, of course, the above commit also broke guile in the exact same
way. And the fix is exactly the same. And there's a guile test too.
NOTE: We should investigate possibly sharing some of this boiler plate
helper code between Python and Guile. But not in this commit.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Consider GDB's builtin prefix set/show prefix sub-commands, if they
are invoked with no sub-command name then they work like this:
(gdb) show print
print address: Printing of addresses is on.
print array: Pretty formatting of arrays is off.
print array-indexes: Printing of array indexes is off.
print asm-demangle: Demangling of C++/ObjC names in disassembly listings is off.
... cut lots of lines ...
(gdb) set print
List of set print subcommands:
set print address -- Set printing of addresses.
set print array -- Set pretty formatting of arrays.
set print array-indexes -- Set printing of array indexes.
set print asm-demangle -- Set demangling of C++/ObjC names in disassembly listings.
... cut lots of lines ...
Type "help set print" followed by set print subcommand name for full documentation.
Type "apropos word" to search for commands related to "word".
Type "apropos -v word" for full documentation of commands related to "word".
Command name abbreviations are allowed if unambiguous.
(gdb)
That is 'show print' lists the values of all settings under the
'print' prefix, and 'set print' lists the help text for all settings
under the 'set print' prefix.
Now, if we try to create something similar using the Python API:
(gdb) python gdb.ParameterPrefix("my-prefix", gdb.COMMAND_NONE)
(gdb) python gdb.Parameter("my-prefix foo", gdb.COMMAND_OBSCURE, gdb.PARAM_BOOLEAN)
(gdb) show my-prefix
(gdb) set my-prefix
Neither 'show my-prefix' or 'set my-prefix' gives us the same details
relating to the sub-commands that we get with the builtin prefix
commands.
This commit aims to address this.
Currently, in cmdpy_init, when a new command is created, we always set
the commands callback function to cmdpy_function. It is within
cmdpy_function that we spot that the command is a prefix command, and
that there is no gdb.Command.invoke method, and so return early.
This commit changes things so that the rules are now:
1. For NON prefix commands, we continue to use cmdpy_function.
2. For prefix commands that do have a gdb.Command.invoke
method (i.e. can handle unknown sub-commands), continue to use
cmdpy_function.
3. For all other prefix commands, don't use cmdpy_function, instead
use GDB's normal callback function for set/show prefixes.
This requires splitting the current call to add_prefix_cmd into either
a call to add_prefix_cmd, add_show_prefix_cmd, or
add_basic_prefix_cmd, as appropriate.
After these changes, we now see this:
(gdb) python gdb.ParameterPrefix("my-prefix", gdb.COMMAND_NONE) │
(gdb) python gdb.Parameter("my-prefix foo", gdb.COMMAND_OBSCURE, gdb.PARAM_BOOLEAN)
(gdb) show my-prefix │
my-prefix foo: The current value of 'my-prefix foo' is "off".
(gdb) set my-prefix
List of "set my-prefix" subcommands:
set my-prefix foo -- Set the current value of 'my-prefix foo'.
Type "help set my-prefix" followed by subcommand name for full documentation.
Type "apropos word" to search for commands related to "word".
Type "apropos -v word" for full documentation of commands related to "word".
Command name abbreviations are allowed if unambiguous.
(gdb)
Which matches how a prefix defined within GDB would act.
I have made the same changes to the Guile API.
|
|
This commit builds on the previous one, and auto-generates a general
description string for parameters defined via the Guile API. This
brings the Guile API closer inline with the Python API. It is worth
reading the previous commit to see some motivating examples.
This commit updates get_doc_string in guile/scm-param.c to allow for
the generation of a general description string. Then in
gdbscm_make_parameter, if '#:doc' was not given, get_doc_string is
used to generate a suitable default.
This does invalidate (and so the commit removes) this comment that was
in gdbscm_make_parameter:
/* If doc is NULL, leave it NULL. See add_setshow_cmd_full. */
First, Python already does exactly what I'm proposing here, and has
done for a while, with no issues reported. And second, I've gone and
read add_setshow_cmd_full, and some of the functions it calls, and can
see no reasoning behind this comment...
... well, there is one reason that I can think of, but I'll discuss
that more below.
With this commit, if I define a parameter like this:
(use-modules (gdb))
(register-parameter! (make-parameter
"print test"
#:command-class COMMAND_NONE
#:parameter-type PARAM_BOOLEAN))
Then, in GDB, I now see this behaviour:
(gdb) help show print test
Show the current value of 'print test'.
This command is not documented.
(gdb) help set print test
Set the current value of 'print test'.
This command is not documented.
(gdb)
The two 'This command is not documented.' lines are new. This output
is what we get from a similarly defined parameter using the Python
API (see the previous commit for an example).
I mentioned above that I can think of one reason for the (now deleted)
comment in gdbscm_make_parameter about leaving the doc field as NULL,
and that is this: consider the following GDB behaviour:
(gdb) help show style filename foreground
Show the foreground color for this property.
(gdb)
Notice there is only a single line of output. If I want to get the
same behaviour from a parameter defined in Guile, I might try skipping
the #:doc argument, but (after this commit), if I do that, GDB will
auto-generate some text for me, giving two lines of output (see
above).
So, next, maybe I try setting #:doc to the empty string, but if I do
that, then I get this:
(use-modules (gdb))
(register-parameter! (make-parameter
"print test"
#:doc ""
#:command-class COMMAND_NONE
#:parameter-type PARAM_BOOLEAN))
(gdb) help show print test
Show the current value of 'print test'.
(gdb)
Notice the blank line, that's not what I wanted. In fact, the only
way to get rid of the second line is to leave the 'doc' variable as
NULL in gdbscm_make_parameter, which, due to the new auto-generation,
is no longer possible.
This issue also existed in the Python API, and was addressed in
commit:
commit 4b68d4ac98aec7cb73a4b276ac7dd38d112786b4
Date: Fri Apr 11 23:45:51 2025 +0100
gdb/python: allow empty gdb.Parameter.__doc__ string
After this commit, an empty __doc__ string for a gdb.Parameter is
translated into a NULL pointer passed to the add_setshow_* command,
which means the second line of output is completely skipped.
And this commit includes the same solution for the Guile API. Now,
with this commit, and the Guile parameter using an empty '#:doc'
string, GDB has the following behaviour:
(gdb) help show print test
Show the current value of 'print test'.
(gdb)
This matches the output for a similarly defined parameter in Python.
|
|
Consider this user defined parameter created in Python:
class test_param(gdb.Parameter):
def __init__(self, name):
super ().__init__(name, gdb.COMMAND_NONE, gdb.PARAM_BOOLEAN)
self.value = True
test_param('print test')
If this is loaded into GDB, then we observe the following behaviour:
(gdb) show print test
The current value of 'print test' is "on".
(gdb) help show print test
Show the current value of 'print test'.
This command is not documented.
(gdb) help set print test
Set the current value of 'print test'.
This command is not documented.
(gdb)
If we now define the same parameter using Guile:
(use-modules (gdb))
(register-parameter! (make-parameter
"print test"
#:command-class COMMAND_NONE
#:parameter-type PARAM_BOOLEAN))
And load this into a fresh GDB session, we see the following:
(gdb) show print test
Command is not documented is off.
(gdb) help show print test
This command is not documented.
(gdb) help set print test
This command is not documented.
(gdb)
The output of 'show print test' doesn't make much sense, and is
certainly worse than the Python equivalent. For both the 'help'
commands it appears as if the first line is missing, but what is
actually happening is that the first line has become 'This command is
not documented.', and the second line is then missing.
The problems can all be traced back to 'get_doc_string' in
guile/scm-param.c. This is the guile version of this function. There
is a similar function in python/py-param.c, however, the Python
version returns one of three different strings depending on the use
case. In contrast, the Guile version just returns 'This command is
not documented.' in all cases.
The three cases that the Python code handles are, the 'set' string,
the 'show' string, and the general 'description' string.
Right now the Guile get_doc_string only returns the general
'description' string, which is funny, because, in
gdbscm_make_parameter, where get_doc_string is used, the one case that
we currently don't need is the general 'description' string. Instead,
right now, the general 'description' string is used for both the 'set'
and 'show' cases.
In this commit I plan to bring the Guile API a little more inline with
the Python API. I will update get_doc_string (in scm-param.c) to
return either a 'set' or 'show' string, and gdbscm_make_parameter will
make use of these strings.
The changes to the Guile get_doc_string are modelled on the Python
version of this function. It is also worth checking out the next
commit, which is related, and helps motivate how the changes have been
implemented in this commit.
After this commit, the same Guile parameter description shown above,
now gives this behaviour:
(gdb) show print test
The current value of 'print test' is off.
(gdb) help show print test
Show the current value of 'print test'.
(gdb) help set print test
Set the current value of 'print test'.
(gdb)
The 'show print test' output now matches the Python behaviour, and is
much more descriptive. The set and show 'help' output are now missing
the second line when compared to the Python output, but the first line
is now correct, and I think this is better than the previous Guile
output.
In the next commit I'll address the problem of the missing second
line.
Existing tests have been updated to expect the new output.
|
|
The manual for gdb.Parameter says:
If NAME consists of multiple words, and no prefix parameter group
can be found, an exception is raised.
This makes sense; we cannot create a parameter within a prefix group,
if the prefix doesn't exist. And this almost works, so:
(gdb) python gdb.Parameter("xxx foo", gdb.COMMAND_NONE, gdb.PARAM_BOOLEAN)
Python Exception <class 'RuntimeError'>: Could not find command prefix xxx.
Error occurred in Python: Could not find command prefix xxx.
The prefix 'xxx' doesn't exist, and we get an error. But, if we try
multiple levels of prefix:
(gdb) python gdb.Parameter("print xxx foo", gdb.COMMAND_NONE, gdb.PARAM_BOOLEAN)
This completes without error, however, we didn't get what we were
maybe expecting:
(gdb) show print xxx foo
Undefined show print command: "xxx foo". Try "help show print".
But we did get:
(gdb) show print foo
The current value of 'print foo' is "off".
GDB stopped scanning the prefix string at the unknown 'xxx', and just
created the parameter there. I don't think this makes sense, nor is
it inline with the manual.
An identical problem exists with gdb.Command creation; GDB stops
parsing the prefix at the first unknown prefix, and just creates the
command there. The manual for gdb.Command says:
NAME is the name of the command. If NAME consists of multiple
words, then the initial words are looked for as prefix commands.
In this case, if one of the prefix commands does not exist, an
exception is raised.
So again, the correct action is, I believe, to raise an exception.
The problem is in gdbpy_parse_command_name (python/py-cmd.c), GDB
calls lookup_cmd_1 to look through the prefix string and return the
last prefix group. If the very first prefix word is invalid then
lookup_cmd_1 returns NULL, and this case is handled. However, if
there is a valid prefix, followed by an invalid prefix, then
lookup_cmd_1 will return a pointer to the last valid prefix list, and
will update the input argument to point to the start of the invalid
prefix word. This final case, where the input is left pointing to an
unknown prefix, was previously not handled.
I've fixed gdbpy_parse_command_name, and added tests for command and
parameter creation to cover this case.
The exact same error is present in the guile API too. The guile
documentation for make-parameter and make-command says the same things
about unknown prefixes resulting in an exception, but the same error
is present in gdbscm_parse_command_name (guile/scm-cmd.c), so I've
fixed that too, and added some tests.
|
|
I noticed that the gdb.Color.escape_sequence() method would produce an
escape sequence even when styling is disabled.
I think this is the wrong choice. Ideally, when styling is
disabled (e.g. with 'set style enabled off'), GDB should not be
producing styled output.
If a GDB extension is using gdb.Color to apply styling to the output,
then currently, the extension should be checking 'show style enabled'
any time Color.escape_sequence() is used. This means lots of code
duplication, and the possibility that some locations will be missed,
which means disabling styling no longer does what it says.
I propose that Color.escape_sequence() should return the empty string
if styling is disabled. A Python extension can then do:
python
c_none = gdb.Color('none')
c_red = gdb.Color('red')
print(c_red.escape_sequence(True)
+ "Text in red."
+ c_none.escape_sequence(True))
end
If styling is enable this will print some red text. And if styling is
disabled, then it will print text in the terminal's default color.
I have applied the same fix to the guile API.
I have extended the tests to cover this case.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Using the trigger patch described in the previous commit, I get:
...
$ gdb
(gdb) <q>error detected on stdin
Fatal signal: Segmentation fault
----- Backtrace -----
0x64c7b3 gdb_internal_backtrace_1
/data/vries/gdb/src/gdb/bt-utils.c:127
0x64c937 _Z22gdb_internal_backtracev
/data/vries/gdb/src/gdb/bt-utils.c:196
0x94db83 handle_fatal_signal
/data/vries/gdb/src/gdb/event-top.c:1021
0x94dd48 handle_sigsegv
/data/vries/gdb/src/gdb/event-top.c:1098
0x7f372be578ff ???
0x10b7c0a _Z9gdb_flushP7ui_file
/data/vries/gdb/src/gdb/utils.c:1527
0xd4b938 gdbpy_flush
/data/vries/gdb/src/gdb/python/python.c:1624
0x7f372d73b276 _PyCFunction_FastCallDict
Objects/methodobject.c:231
0x7f372d73b276 _PyCFunction_FastCallKeywords
Objects/methodobject.c:294
0x7f372d794a09 call_function
Python/ceval.c:4851
0x7f372d78e838 _PyEval_EvalFrameDefault
Python/ceval.c:3351
0x7f372d796e6e PyEval_EvalFrameEx
Python/ceval.c:754
0x7f372d796e6e _PyFunction_FastCall
Python/ceval.c:4933
0x7f372d796e6e _PyFunction_FastCallDict
Python/ceval.c:5035
0x7f372d6fefc8 _PyObject_FastCallDict
Objects/abstract.c:2310
0x7f372d6fefc8 _PyObject_Call_Prepend
Objects/abstract.c:2373
0x7f372d6fe162 _PyObject_FastCallDict
Objects/abstract.c:2331
0x7f372d700705 callmethod
Objects/abstract.c:2583
0x7f372d700705 _PyObject_CallMethodId
Objects/abstract.c:2640
0x7f372d812a41 flush_std_files
Python/pylifecycle.c:699
0x7f372d81281d Py_FinalizeEx
Python/pylifecycle.c:768
0xd4d49b finalize_python
/data/vries/gdb/src/gdb/python/python.c:2308
0x9587eb _Z17ext_lang_shutdownv
/data/vries/gdb/src/gdb/extension.c:330
0xfd98df _Z10quit_forcePii
/data/vries/gdb/src/gdb/top.c:1817
0x6b3080 _Z12quit_commandPKci
/data/vries/gdb/src/gdb/cli/cli-cmds.c:483
0x1056577 stdin_event_handler
/data/vries/gdb/src/gdb/ui.c:131
0x1986970 handle_file_event
/data/vries/gdb/src/gdbsupport/event-loop.cc:551
0x1986f4b gdb_wait_for_event
/data/vries/gdb/src/gdbsupport/event-loop.cc:672
0x1985e0c _Z16gdb_do_one_eventi
/data/vries/gdb/src/gdbsupport/event-loop.cc:263
0xb66f2e start_event_loop
/data/vries/gdb/src/gdb/main.c:402
0xb670ba captured_command_loop
/data/vries/gdb/src/gdb/main.c:466
0xb68b9b captured_main
/data/vries/gdb/src/gdb/main.c:1344
0xb68c44 _Z8gdb_mainP18captured_main_args
/data/vries/gdb/src/gdb/main.c:1363
0x41a3b1 main
/data/vries/gdb/src/gdb/gdb.c:38
---------------------
A fatal error internal to GDB has been detected, further
debugging is not possible. GDB will now terminate.
This is a bug, please report it. For instructions, see:
<https://www.gnu.org/software/gdb/bugs/>.
Segmentation fault (core dumped)
$ q
...
Fix this in gdbpy_flush by checking for nullptr gdb_stdout/gdb_stderr (and
likewise in ioscm_flush) such that we get instead:
...
$ gdb
(gdb) <q>error detected on stdin
$ q
...
Tested on x86_64-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.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>
|
|
This cleans up the last codespell reports in the Guile directory and
adds gdb/guile to pre-commit.
It also tells codespell to ignore URLs. I think this is warranted
because many URLs don't really contain words per se; and furthermore
if any URL-checking is needed at all, it would be for liveness and not
spelling.
Also I was wondering why the codespell config is in contrib and not
gdb/setup.cfg.
Approved-By: Tom de Vries <tdevries@suse.de>
|
|
All 3 valid Guile pretty printer display hints are treated as the
value "string". As a result, if a printer specifies "array" or
"map", the output is instead formatted as a string.
This humble patch corrects the issue.
|
|
Fix typos:
...
gdb/guile/scm-lazy-string.c:41: sting ==> string
gdb/guile/lib/gdb/iterator.scm:65: satify ==> satisfy
...
|
|
I build gdb with libguile v2.0.9, and ran into:
...
In file included from /usr/include/guile/2.0/libguile.h:56,
from ../../gdb/guile/guile-internal.h:30,
from ../../gdb/guile/scm-arch.c:26:
/usr/include/guile/2.0/libguile/inline.h: In function 'int scm_is_pair(SCM)':
/usr/include/guile/2.0/libguile/tags.h:97:53: error: \
operation on '*0' may be undefined [-Werror=sequence-point]
# define SCM_UNPACK(x) ((scm_t_bits) (0? (*(SCM*)0=(x)): x))
~~~~~~~~~^~~~~
...
Fix this by using SCM_DEBUG_TYPING_STRICTNESS 0.
We were already using this for c++20 due to a Werror=volatile in SCM_UNPACK
when using libguile v2.0.10.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.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.
|
|
With gcc 10 and -std=c++20, we run into the same problem as reported in commit
6feae66da1d ("[gdb/build, c++20] Handle deprecated std::allocator::construct").
The problem was fixed using:
...
-template<typename T, typename A = std::allocator<T>>
+template<typename T,
+ typename A
+#if __cplusplus >= 202002L
+ = std::pmr::polymorphic_allocator<T>
+#else
+ = std::allocator<T>
+#endif
+ >
...
but that doesn't work for gcc 10, because it defines __cplusplus differently:
...
$ echo | g++-10 -E -dD -x c++ - -std=c++20 2>&1 | grep __cplusplus
#define __cplusplus 201709L
$ echo | g++-11 -E -dD -x c++ - -std=c++20 2>&1 | grep __cplusplus
#define __cplusplus 202002L
...
Fix this by using the library feature test macro
__cpp_lib_polymorphic_allocator [1], which is undefined for c++17 and defined
for c++20:
...
$ echo | g++-10 -E -dD -x c++ - -include memory_resource -std=c++17 2>&1 \
| grep __cpp_lib_polymorphic_allocator
$ echo | g++-10 -E -dD -x c++ - -include memory_resource -std=c++20 2>&1 \
| grep __cpp_lib_polymorphic_allocator
#define __cpp_lib_polymorphic_allocator 201902L
$
...
A similar problem exists for commit 3173529d7de ("[gdb/guile, c++20] Work
around Werror=volatile in libguile.h"). Fix this by testing for 201709L
instead.
Tested on x86_64-linux, by building gdb with
{gcc 10, clang 17.0.6} x {-std=c++17, -std=c++20}.
PR build/32503
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32503
Approved-By: Tom Tromey <tom@tromey.com>
[1] https://en.cppreference.com/w/cpp/feature_test#cpp_lib_polymorphic_allocator
|
|
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>
|
|
This converts the type copying code to use the new hash map.
Change-Id: I35f0a4946dcc5c5eb84820126cf716b600f3302f
Co-Authored-By: Tom Tromey <tom@tromey.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Eli mentioned [1] that given that we use US English spelling in our
documentation, we should use "behavior" instead of "behaviour".
In wikipedia-common-misspellings.txt there's a rule:
...
behavour->behavior, behaviour
...
which leaves this as a choice.
Add an overriding rule to hardcode the choice to common-misspellings.txt:
...
behavour->behavior
...
and add a rule to rewrite behaviour into behavior:
...
behaviour->behavior
...
and re-run spellcheck.sh on gdb*.
Tested on x86_64-linux.
[1] https://sourceware.org/pipermail/gdb-patches/2024-November/213371.html
|
|
A question was asked on stackoverflow.com about the guile function
get-basic-type[1] which is mentioned in the docs along with an example
of its use.
The problem is, the function was apparently never actually added to
GDB. But it turns out that it's pretty easy to implement, so lets add
it now. Better late than never.
The implementation mirrors the Python get_basic_type function. I've
added a test which is a copy of the documentation example.
One issue is that the docs suggest that the type will be returned as
just "int", however, I'm not sure what this actually means. It makes
more sense that the function return a gdb:type object which would be
represented as "#<gdb:type int>", so I've updated the docs to show
this output.
[1] https://stackoverflow.com/questions/79058691/unbound-variable-get-basic-type-in-gdb-guile-session
Reviewed-By: Kevin Buettner <kevinb@redhat.com>
|
|
When building gdb with -std=c++20, I run into:
...
In file included from /usr/include/guile/2.0/libguile/__scm.h:479,
from /usr/include/guile/2.0/libguile.h:31,
from /data/vries/gdb/src/gdb/guile/guile-internal.h:30,
from /data/vries/gdb/src/gdb/guile/guile.c:37:
/usr/include/guile/2.0/libguile/gc.h: In function ‘scm_unused_struct* \
scm_cell(scm_t_bits, scm_t_bits)’:
/usr/include/guile/2.0/libguile/tags.h:98:63: error: using value of \
assignment with ‘volatile’-qualified left operand is deprecated \
[-Werror=volatile]
98 | # define SCM_UNPACK(x) ((scm_t_bits) (0? (*(volatile SCM *)0=(x)): x))
| ~~~~~~~~~~~~~~~~~~~^~~~~
...
This was reported upstream [1].
Work around this by using SCM_DEBUG_TYPING_STRICTNESS == 0 instead of the
default SCM_DEBUG_TYPING_STRICTNESS == 1.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR guile/30767
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30767
[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=65333
|
|
Unfortunately we have two different types of filename completion in
GDB.
The majority of commands have what I call unquoted filename
completion, this is for commands like 'set logging file ...', 'target
core ...', and 'add-auto-load-safe-path ...'. For these commands
everything after the command name (that is not a command option) is
treated as a single filename. If the filename contains white space
then this does not need to be escaped, nor does the filename need to
be quoted. In fact, the filename argument is not de-quoted, and does
not have any escaping removed, so if a user does try to add such
things, they will be treated as part of the filename. As an example:
(gdb) target core "/path/that contains/some white space"
Will look for a directory calls '"' (double quotes) in the local
directory.
A small number of commands do de-quote and remove escapes from
filename arguments. These command accept what I call quoted and
escaped filenames. Right now these are the commands that specify the
file for GDB to debug, so:
file
exec-file
symbol-file
add-symbol-file
remove-symbol-file
As an example of this in action:
(gdb) file "/path/that contains/some white space"
In this case GDB would load the file:
/path/that contains/some white space
Current filename completion always assumes that filenames can be
quoted, though escaping doesn't work in completion right now. But the
assumption that quoting is allowed is clearly wrong.
This commit splits filename completion into two. The existing
filename_completer is retained, and is used for unquoted filenames. A
second filename_maybe_quoted_completer is added which can be used for
completing quoted filenames.
The filename completion test has been extended to cover more cases.
As part of the extended testing I need to know the character that
should be used to separate filenames within a path. For this TCL 8.6+
has $::tcl_platform(pathSeparator). To support older versions of TCL
I've added some code to testsuite/lib/gdb.exp.
You might notice that after this commit the completion for unquoted
files is all done in the brkchars phase, that is the function
filename_completer_handle_brkchars calculates the completions and
marks the completion_tracker as using a custom word point. The reason
for this is that we don't want to break on white space for this
completion, but if we rely on readline to find the completion word,
readline will consider the entire command line, and with no white
space in the word break character set, readline will end up using the
entire command line as the word to complete.
For now at least, the completer for quoted filenames does generate its
completions during the completion phase, though this is going to
change in a later commit.
|
|
By default GDB will be printing the hex payload of the ptwrite package as
auxiliary information. To customize this, the user can register a ptwrite
filter function in python, that takes the payload and the PC as arguments and
returns a string which will be printed instead. Registering the filter
function is done using a factory pattern to make per-thread filtering easier.
Approved-By: Markus Metzger <markus.t.metzger@intel.com>
|
|
C++ 11 has a built-in attribute for this, no need to use a compat macro.
Change-Id: I90e4220d26e8f3949d91761f8a13cd9c37da3875
Reviewed-by: Lancelot Six <lancelot.six@amd.com>
|
|
Rename to m_pspace, add getter. An objfile's pspace never changes, so
no setter is necessary.
Change-Id: If4dfb300cb90dc0fb9776ea704ff92baebb8f626
|
|
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>
|
|
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>
|
|
Right now, Python is shut down via a final cleanup. However, it seems
to me that it is better for extension languages to be shut down
explicitly, after all the ordinary final cleanups are run. The main
reason for this is that a subsequent patch adds another case like
finalize_values; and rather than add a series of workarounds for
Python shutdown, it seemed better to let these be done via final
cleanups, and then have Python shutdown itself be the special case.
|
|
Since commit 6771fc6f1d9 "Use a .def file for domain_enum", the
sym-domains.def file has been introduced, and requires the user to
define the DOMAIN(x) macro.
On older systems (centos-7 with glibc-2.17 for example), this DOMAIN
macro conflicts with another macro defined in /usr/include/math.h.
Fix this conflict by changing sym-domains.def to use a macro named
SYM_DOMAIN instead of DOMAIN.
Change-Id: I679df30e2bd2f4333343f16bbd2a3511a37550a3
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This changes lookup_symbol and associated APIs to accept
domain_search_flags rather than a domain_enum.
Note that this introduces some new constants to Python and Guile. I
chose to break out the documentation patch for this, because the
internals here do not change until a later patch, and it seemed
simpler to patch the docs just once, rather than twice.
|
|
Future patches will change and reuse the names from domain_enum. This
patch makes this less error-prone by having a single point to define
these names, using the typical gdb ".def" file.
|
|
This commit is the result of the following actions:
- Running gdb/copyright.py to update all of the copyright headers to
include 2024,
- Manually updating a few files the copyright.py script told me to
update, these files had copyright headers embedded within the
file,
- Regenerating gdbsupport/Makefile.in to refresh it's copyright
date,
- Using grep to find other files that still mentioned 2023. If
these files were updated last year from 2022 to 2023 then I've
updated them this year to 2024.
I'm sure I've probably missed some dates. Feel free to fix them up as
you spot them.
|
|
Some functions related to the handling of registers in frames accept
"this frame", for which we want to read or write the register values,
while other functions accept "the next frame", which is the frame next
to that. The later is needed because we sometimes need to read register
values for a frame that does not exist yet (usually when trying to
unwind that frame-to-be).
value_of_register and value_of_register_lazy both take "this frame",
even if what they ultimately want internally is "the next frame". This
is annoying if you are in a spot that currently has "the next frame" and
need to call one of these functions (which happens later in this
series). You need to get the previous frame only for those functions to
get the next frame again. This is more manipulations, more chances of
mistake.
I propose to change these functions (and a few more functions in the
subsequent patches) to operate on "the next frame". Things become a bit
less awkward when all these functions agree on which frame they take.
So, in this patch, change value_of_register_lazy and value_of_register
to take "the next frame" instead of "this frame". This adds a lot of
get_next_frame_sentinel_okay, but if we convert the user registers API
to also use "the next frame" instead of "this frame", it will get simple
again.
Change-Id: Iaa24815e648fbe5ae3c214c738758890a91819cd
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
|
|
Since GDB now requires C++17, we don't need the internally maintained
gdb::optional implementation. This patch does the following replacing:
- gdb::optional -> std::optional
- gdb::in_place -> std::in_place
- #include "gdbsupport/gdb_optional.h" -> #include <optional>
This change has mostly been done automatically. One exception is
gdbsupport/thread-pool.* which did not use the gdb:: prefix as it
already lives in the gdb namespace.
Change-Id: I19a92fa03e89637bab136c72e34fd351524f65e9
Approved-By: Tom Tromey <tom@tromey.com>
Approved-By: Pedro Alves <pedro@palves.net>
|
|
Make the current_program_space references bubble up a bit.
Change-Id: Id047a48cc8d8a45504cdbb5960bafe3e7735d652
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I noticed a comment by an include and remembered that I think these
don't really provide much value -- sometimes they are just editorial,
and sometimes they are obsolete. I think it's better to just remove
them. Tested by rebuilding.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
This replaces some casts to 'watchpoint *' with checked_static_cast.
In one spot, an unnecessary block is also removed.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
