Add a new argument to the gdb.Value.format_string method, 'styling'.
This argument is False by default.
When this argument is True, then the returned string can contain output
styling escape sequences.
When this argument is False, then the returned string will not contain
any styling escape sequences.
If the returned string is going to be printed to the user, then it is
often nice to retain the GDB styling.
For the testing, we need to adjust the TERM environment variable, as
we do for all the styling tests. I'm now running all of the C tests
in gdb.python/py-format-string.exp in an environment where styling
could be generated, but only my new test should actually produce
styled output, hopefully this will catch the case where a bug might
cause format_string to always produce styled output.
GDB already has a flag to suppress printing notification events, such
as thread and inferior context switches, on the CLI. This is used
internally when executing commands. Make the flag available to the
user via a new command. This is expected to be useful in scripts.
For instance, suppose that when Inferior 1 gets to a certain state,
you want to add and set up a new inferior using the commands below,
but you also want to have a reduced/clean output.
define do-setup
printf "Setting up Inferior 2...\n"
add-inferior -exec a.out
inferior 2
break file.c:3
run
inferior 1
printf "Done\n"
end
Currently, GDB prints
(gdb) do-setup
Setting up Inferior 2...
[New inferior 2]
Added inferior 2 on connection 1 (native)
[Switching to inferior 2 [<null>] (/tmp/a.out)]
Breakpoint 2 at 0x1155: file file.c, line 3.
Thread 2.1 "a.out" hit Breakpoint 2, main () at file.c:3
3 return 0;
[Switching to inferior 1 [process 7670] (/tmp/test)]
[Switching to thread 1.1 (process 7670)]
#0 main () at test.c:2
2 int a = 1;
Done
GDB's Python API make it possible to capture and return GDB's output,
but this does not work for all the streams. In particular, CLI
notification events are not captured:
(gdb) python gdb.execute("do-setup", False, True)
[Switching to inferior 2 [<null>] (/tmp/a.out)]
Thread 2.1 "a.out" hit Breakpoint 2, main () at file.c:3
3 return 0;
[Switching to inferior 1 [process 8263] (/tmp/test)]
[Switching to thread 1.1 (process 8263)]
#0 main () at test.c:2
2 int a = 1;
You can use the new "set suppress-cli-notifications" command to
suppress the output:
(gdb) set suppress-cli-notifications on
(gdb) do-setup
Setting up Inferior 2...
[New inferior 2]
Added inferior 2 on connection 1 (native)
Breakpoint 2 at 0x1155: file file.c, line 3.
Done
This started by noticing that the docs for 'winheight' are out of
date, the docs currently give a specific list of possible window
names. However, now that windows can be implemented in Python, it is
not possible to list all possible names.
I now link the user to a mechanism by which they can discover the
valid names for themselves at run time (by using 'info win'). That,
and the fact that gdb provides tab-completion of the name at the
command line, feels good enough.
Finally, I noticed that the docs for 'win info' don't explicitly say
that the name of the window is given in the output. This could
probably have been inferred, but given I'm now linking to this as a
mechanism to find the window name, I'd prefer to mention that the name
can be found in the output.
This commit attempts to improve the help text that is generated for
gdb.Parameter objects when the user fails to provide their own
documentation.
Documentation for a gdb.Parameter is currently pulled from two
sources: the class documentation string, and the set_doc/show_doc
class attributes. Thus, a fully documented parameter might look like
this:
class Param_All (gdb.Parameter):
"""This is the class documentation string."""
show_doc = "Show the state of this parameter"
set_doc = "Set the state of this parameter"
def get_set_string (self):
val = "on"
if (self.value == False):
val = "off"
return "Test Parameter has been set to " + val
def __init__ (self, name):
super (Param_All, self).__init__ (name, gdb.COMMAND_DATA, gdb.PARAM_BOOLEAN)
self._value = True
Param_All ('param-all')
Then in GDB we see this:
(gdb) help set param-all
Set the state of this parameter
This is the class documentation string.
Which is fine. But, if the user skips both of the documentation parts
like this:
class Param_None (gdb.Parameter):
def get_set_string (self):
val = "on"
if (self.value == False):
val = "off"
return "Test Parameter has been set to " + val
def __init__ (self, name):
super (Param_None, self).__init__ (name, gdb.COMMAND_DATA, gdb.PARAM_BOOLEAN)
self._value = True
Param_None ('param-none')
Now in GDB we see this:
(gdb) help set param-none
This command is not documented.
This command is not documented.
That's not great, the duplicated text looks a bit weird. If we drop
different parts we get different results. Here's what we get if the
user drops the set_doc and show_doc attributes:
(gdb) help set param-doc
This command is not documented.
This is the class documentation string.
That kind of sucks, we say it's undocumented, then proceed to print
the documentation. Finally, if we drop the class documentation but
keep the set_doc and show_doc:
(gdb) help set param-set-show
Set the state of this parameter
This command is not documented.
That seems OK.
So, I think there's room for improvement.
With this patch, for the four cases above we now see this:
# All values provided by the user, no change in this case:
(gdb) help set param-all
Set the state of this parameter
This is the class documentation string.
# Nothing provided by the user, the first string is now different:
(gdb) help set param-none
Set the current value of 'param-none'.
This command is not documented.
# Only the class documentation is provided, the first string is
# changed as in the previous case:
(gdb) help set param-doc
Set the current value of 'param-doc'.
This is the class documentation string.
# Only the set_doc and show_doc are provided, this case is unchanged
# from before the patch:
(gdb) help set param-set-show
Set the state of this parameter
This command is not documented.
The one place where this change might be considered a negative is when
dealing with prefix commands. If we create a prefix command but don't
supply the set_doc / show_doc strings, then this is what we saw before
my patch:
(gdb) python Param_None ('print param-none')
(gdb) help set print
set print, set pr, set p
Generic command for setting how things print.
List of set print subcommands:
... snip ...
set print param-none -- This command is not documented.
... snip ...
And after my patch:
(gdb) python Param_None ('print param-none')
(gdb) help set print
set print, set pr, set p
Generic command for setting how things print.
List of set print subcommands:
... snip ...
set print param-none -- Set the current value of 'print param-none'.
... snip ...
This seems slightly less helpful than before, but I don't think its
terrible.
Additionally, I've changed what we print when the get_show_string
method is not provided in Python.
Back when gdb.Parameter was first added to GDB, we didn't provide a
show function when registering the internal command object within
GDB. As a result, GDB would make use of its "magic" mangling of the
show_doc string to create a sentence that would display the current
value (see deprecated_show_value_hack in cli/cli-setshow.c).
However, when we added support for the get_show_string method to
gdb.Parameter, there was an attempt to maintain backward compatibility
by displaying the show_doc string with the current value appended, see
get_show_value in py-param.c. Unfortunately, this isn't anywhere
close to what deprecated_show_value_hack does, and the results are
pretty poor, for example, this is GDB before my patch:
(gdb) show param-none
This command is not documented. off
I think we can all agree that this is pretty bad.
After my patch, we how show this:
(gdb) show param-none
The current value of 'param-none' is "off".
Which at least is a real sentence, even if it's not very informative.
This patch does change the way that the Python API behaves slightly,
but only in the cases when the user has missed providing GDB with some
information. In most cases I think the new behaviour is a lot better,
there's the one case (noted above) which is a bit iffy, but I think is
still OK.
I've updated the existing gdb.python/py-parameter.exp test to cover
the modified behaviour.
Finally, I've updated the documentation to (I hope) make it clearer
how the various bits of help text come together.
Add a new function gdb.history_count to the Python api, this function
returns an integer, the number of items in GDB's value history.
This is useful if you want to pull items from the history by their
absolute number, for example, if you wanted to show a complete history
list. Previously we could figure out how many items are in the
history list by trying to fetch the items, and then catching the
exception when the item is not available, but having this function
seems nicer.
It's sometimes useful to temporarily set some gdb parameter from
Python. Now that the 'endian' crash is fixed, and now that the
current language is no longer captured by the Python layer, it seems
reasonable to add a helper function for this situation.
This adds a new gdb.with_parameter function. This creates a context
manager which temporarily sets some parameter to a specified value.
The old value is restored when the context is exited. This is most
useful with the Python "with" statement:
with gdb.with_parameter('language', 'ada'):
... do Ada stuff
This also adds a simple function to set a parameter,
gdb.set_parameter, as suggested by Andrew.
This is PR python/10790.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=10790
The description of the Window.click method doesn't mention where the
coordinates are anchored (it's the top left corner).
This minor tweak just mentions this point.
I noticed two places in the docs where we appear to be missing @r.
makeinfo seems to do the correct things despite these being
missing (at least, I couldn't see any difference in the pdf or info
output), but it doesn't hurt to have the @r in place.
In a later commit I want to address an issue with the Python pygments
based code styling solution. As this approach is only used when the
GNU Source Highlight library is not available, testing bugs in this
area can be annoying, as it requires GDB to be rebuilt with use of GNU
Source Highlight disabled.
This commit adds a pair of new maintenance commands:
maintenance set gnu-source-highlight enabled on|off
maintenance show gnu-source-highlight enabled
these commands can be used to disable use of the GNU Source Highlight
library, allowing me, in a later commit, to easily test bugs that
would otherwise be masked by GNU Source Highlight being used.
I made this a maintenance command, rather than a general purpose
command, as it didn't seem like this was something a general user
would need to adjust. We can always convert the maintenance command
to a general command later if needed.
There's no test for this here, but this feature will be used in a
later commit.
This commit adds a new 'maint flush source-cache' command, this
flushes the cache of source file contents.
After flushing GDB is forced to reread source files the next time any
source lines are to be displayed.
I've added a test for this new feature. The test is a little weird,
in that it modifies a source file after compilation, and makes use of
the cache flush so that the changes show up when listing the source
file. I'm not sure when such a situation would ever crop up in real
life, but maybe we can imagine such cases.
In reality, this command is useful for testing the syntax highlighting
within GDB, we can adjust the syntax highlighting settings, flush the
cache, and then get the file contents re-highlighted using the new
settings.
Rename 'set debug lin-lwp' to 'set debug linux-nat' and 'show debug
lin-lwp' to 'show debug linux-nat'.
I've updated the documentation and help text to match, as well as
making it clear that the debug that is coming out relates to all
aspects of Linux native inferior support, not just the LWP aspect of
it.
The boundary between general "native" target debug, and the lwp
specific part of that debug was always a little blurry, but the actual
debug variable inside GDB is debug_linux_nat, and the print routine
linux_nat_debug_printf, is used throughout the linux-nat.c file, not
just for lwp related debug, so the new name seems to make more sense.
Building on the previous commit, this makes use of a trailing @ to
split long @deffn lines in the guile.texi source file. This splitting
doesn't change how the document is laid out by texinfo.
I have also wrapped keyword and argument name pairs in @w{...} to
prevent line breaks appearing between the two. I've currently only
done this for the longer @deffn lines, where a line break is
possible. This makes the @deffn lines much nicer to read in the
generated pdf.
Most guile procedures in the guile.texi file are defined like:
@deffn {Scheme Procedure} name arg1 arg2 arg3
But there are two places where we do this:
@deffn {Scheme Procedure} (name arg1 arg2 arg3)
Notice the added (...). Though this does represent how a procedure
call is written in scheme, it's not the normal style throughout the
manual. I also checked the 'info guile' info page to see how they
wrote there declarations, and they use the first style too.
The second style also has the drawback that index entries are added as
'(name', and so they are grouped in the '(' section of the index,
which is not very user friendly.
In this commit I've changed the definitions of make-command and
make-parameter to use the first style.
The procedure declaration lines can get pretty long with all of the
arguments, and this was true for both of the procedures I am changing
in this commit. I have made use of a trailing '@' to split the deffn
lines, and keep them under 80 characters in the texi source. This
makes no difference to how the final document looks.
Finally, our current style for keyword arguments, appears to be:
[#:keyword-name argument-name]
I don't really understand the reason for this, 'info guile' just seems
to use:
[#:keyword-name]
which seems just as good to me. But I don't propose to change
that just now. What I do notice though, is that sometimes, texinfo
will place a line break between the keyword-name and the
argument-name, for example, the pdf of make-command is:
make-command name [#:invoke invoke] [#:command-class
command-class] [#:completer-class completer] [#:prefix? prefix] [#:doc
doc-string]
Notice the line break after '#:command-class' and after '#:doc',
neither of which are ideal. And so, for the two commands I am
changing in this commit, I have made use of @w{...} to prevent line
breaks between the keyword-name and the argument-name. Now the pdf
looks like this:
make-command name [#:invoke invoke]
[#:command-class command-class] [#:completer-class completer]
[#:prefix? prefix] [#:doc doc-string]
Which seems much better. I'll probably update the other deffn lines
at some point.
This commit updates the copyright year in some files where
we have a copyright year outside of the copyright year,
and thus are not included in gdb's copyright.py script.
This commit brings all the changes made by running gdb/copyright.py
as per GDB's Start of New Year Procedure.
For the avoidance of doubt, all changes in this commits were
performed by the script.
This commit ensures that the following settings are cloned from one
inferior to the new one when processing the clone-inferior command:
- inferior-tty
- environment variables
- cwd
- args
Some of those parameters can be passed as command line arguments to GDB
(-args and -tty), so one could expect the clone-inferior to respect
those flags. The following debugging session illustrates that:
gdb -nx -quiet -batch \
-ex "show args" \
-ex "show inferior-tty" \
-ex "clone-inferior" \
-ex "inferior 2" \
-ex "show args" \
-ex "show inferior-tty" \
-tty=/some/tty \
-args echo foo bar
Argument list to give program being debugged when it is started is "foo bar".
Terminal for future runs of program being debugged is "/some/tty".
[New inferior 2]
Added inferior 2.
[Switching to inferior 2 [<null>] (/bin/echo)]
Argument list to give program being debugged when it is started is "".
Terminal for future runs of program being debugged is "".
The other properties this commit copies on clone (i.e. CWD and the
environment variables) are included since they are related (in the sense
that they influence the runtime behavior of the program) even if they
cannot be directly set using command line switches.
There is a chance that this patch changes existing user workflow. I
think that this change is mostly harmless. If users want to start a new
inferior based on an existing one, they probably already propagate those
settings to the new inferior in some way.
Tested on x86_64-linux.
Change-Id: I3b1f28b662f246228b37bb24c2ea1481567b363d
I noticed that the mi-async setting was not referenced from the index
in any way, this commit tries to rectify that a bit.
The @cindex lines I think are not controversial, these same index
entries are used elsewhere in the manual for async related topics (see
@node Background Execution).
The only bit that might be controversial is that I've added a @kindex
entry for 'set mi-async' when the command is documented as '-gdb-set
mi-async' (with a similar difference for the show/-gdb-show).
My reasoning here is that nothing else is indexed under -gdb-set or
-gdb-show, and as -gdb-set/-gdb-show are just the MI equivalent for
set/show anything that is documented under set/show can be adjusted
using -gdb-set/-gdbshow, and so, I've tried to keep the index
consistent for mi-async.
Add new commands:
set debug threads on|off
show debug threads
Prints additional debug information relating to thread creation and
deletion.
GDB already announces when threads are created of course.... most of
the time, but sometimes threads are added silently, in which case this
debug message is the only mechanism to see the thread being added.
Also, though GDB does announce when a thread exits, it doesn't
announce when the thread object is deleted, I've added a debug message
for that.
Additionally, having message printed through the debug system will
cause the messages to be nested to an appropriate depth when other
debug sub-systems are turned on (especially things like `infrun` and
`lin-lwp`).
This command adds the "exit" command as an alias for the "quit"
command, as requested in PR gdb/28406.
The documentation is also updated to mention this new command.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28406
The documentation suggests that we implement gdb.Value.__init__,
however, this is not currently true, we really implement
gdb.Value.__new__. This will cause confusion if a user tries to
sub-class gdb.Value. They might write:
class MyVal (gdb.Value):
def __init__ (self, val):
gdb.Value.__init__(self, val)
obj = MyVal(123)
print ("Got: %s" % obj)
But, when they source this code they'll see:
(gdb) source ~/tmp/value-test.py
Traceback (most recent call last):
File "/home/andrew/tmp/value-test.py", line 7, in <module>
obj = MyVal(123)
File "/home/andrew/tmp/value-test.py", line 5, in __init__
gdb.Value.__init__(self, val)
TypeError: object.__init__() takes exactly one argument (the instance to initialize)
(gdb)
The reason for this is that, as we don't implement __init__ for
gdb.Value, Python ends up calling object.__init__ instead, which
doesn't expect any arguments.
The Python docs suggest that the reason why we might take this
approach is because we want gdb.Value to be immutable:
https://docs.python.org/3/c-api/typeobj.html#c.PyTypeObject.tp_new
But I don't see any reason why we should require gdb.Value to be
immutable when other types defined in GDB are not. This current
immutability can be seen in this code:
obj = gdb.Value(1234)
print("Got: %s" % obj)
obj.__init__ (5678)
print("Got: %s" % obj)
Which currently runs without error, but prints:
Got: 1234
Got: 1234
In this commit I propose that we switch to using __init__ to
initialize gdb.Value objects.
This does introduce some additional complexity, during the __init__
call a gdb.Value might already be associated with a gdb value object,
in which case we need to cleanly break that association before
installing the new gdb value object. However, the cost of doing this
is not great, and the benefit - being able to easily sub-class
gdb.Value seems worth it.
After this commit the first example above works without error, while
the second example now prints:
Got: 1234
Got: 5678
In order to make it easier to override the gdb.Value.__init__ method,
I have tweaked the definition of gdb.Value.__init__. The second,
optional argument to __init__ is a gdb.Type, if this argument is not
present then GDB figures out a suitable type.
However, if we want to override the __init__ method in a sub-class,
and still support the default argument, it is easier to write:
class MyVal (gdb.Value):
def __init__ (self, val, type=None):
gdb.Value.__init__(self, val, type)
Currently, passing None for the Type will result in an error:
TypeError: type argument must be a gdb.Type.
After this commit I now allow the type argument to be None, in which
case GDB figures out a suitable type just as if the type had not been
passed at all.
Unless a user is trying to reinitialize a value, or create sub-classes
of gdb.Value, there should be no user visible changes after this
commit.
This adds a 'task apply' command, which is the Ada tasking analogue of
'thread apply'. Unlike 'thread apply', it doesn't offer the
'ascending' flag; but otherwise it's essentially the same.
This commits adds a new sub-class of gdb.TargetConnection,
gdb.RemoteTargetConnection. This sub-class is created for all
'remote' and 'extended-remote' targets.
This new sub-class has one additional method over its base class,
'send_packet'. This new method is equivalent to the 'maint
packet' CLI command, it allows a custom packet to be sent to a remote
target.
The outgoing packet can either be a bytes object, or a Unicode string,
so long as the Unicode string contains only ASCII characters.
The result of calling RemoteTargetConnection.send_packet is a bytes
object containing the reply that came from the remote.
In a later commit I will add a Python API to access the 'maint packet'
functionality, that is, sending a user specified packet to the target.
To make implementing this easier, this commit refactors how this
command is currently implemented so that the packet_command function
is now global.
The new global send_remote_packet function takes an object that is an
implementation of an abstract interface. Two functions within this
interface are then called, one just before a packet is sent to the
remote target, and one when the reply has been received from the
remote target. Using an interface object in this way allows (1) for
the error checking to be done before the first callback is made, this
means we only print out what packet it being sent once we know we are
going to actually send it, and (2) we don't need to make a copy of the
reply if all we want to do is print it.
One user visible changes after this commit are the error
messages, which I've changed to be less 'maint packet' command
focused, this will make them (I hope) better for when
send_remote_packet can be called from Python code.
So: "command can only be used with remote target"
Becomes: "packets can only be sent to a remote target"
And: "remote-packet command requires packet text as argument"
Becomes: "a remote packet must not be empty"
Additionally, in this commit, I've added support for packet replies
that contain binary data. Before this commit, the code that printed
the reply treated the reply as a C string, it assumed that the string
only contained printable characters, and had a null character only at
the end.
One way to show the problem with this is if we try to read the auxv
data from a remote target, the auxv data is binary, so, before this
commit:
(gdb) target remote :54321
...
(gdb) maint packet qXfer:auxv:read::0,1000
sending: "qXfer:auxv:read::0,1000"
received: "l!"
(gdb)
And after this commit:
(gdb) target remote :54321
...
(gdb) maint packet qXfer:auxv:read::0,1000
sending: "qXfer:auxv:read::0,1000"
received: "l!\x00\x00\x00\x00\x00\x00\x00\x00\xf0\xfc\xf7\xff\x7f\x00\x00\x10\x00\x00\x00\x00\x00\x00\x00\xff\xf>
(gdb)
The binary contents of the reply are now printed as escaped hex.
This commit adds a new object type gdb.TargetConnection. This new
type represents a connection within GDB (a connection as displayed by
'info connections').
There's three ways to find a gdb.TargetConnection, there's a new
'gdb.connections()' function, which returns a list of all currently
active connections.
Or you can read the new 'connection' property on the gdb.Inferior
object type, this contains the connection for that inferior (or None
if the inferior has no connection, for example, it is exited).
Finally, there's a new gdb.events.connection_removed event registry,
this emits a new gdb.ConnectionEvent whenever a connection is removed
from GDB (this can happen when all inferiors using a connection exit,
though this is not always the case, depending on the connection type).
The gdb.ConnectionEvent has a 'connection' property, which is the
gdb.TargetConnection being removed from GDB.
The gdb.TargetConnection has an 'is_valid()' method. A connection
object becomes invalid when the underlying connection is removed from
GDB (as discussed above, this might be when all inferiors using a
connection exit, or it might be when the user explicitly replaces a
connection in GDB by issuing another 'target' command).
The gdb.TargetConnection has the following read-only properties:
'num': The number for this connection,
'type': e.g. 'native', 'remote', 'sim', etc
'description': The longer description as seen in the 'info
connections' command output.
'details': A string or None. Extra details for the connection, for
example, a remote connection's details might be
'hostname:port'.
Before commit 3b6acaee89 "Update more calls to add_prefix_cmd" we had the
following output for "show logging file":
...
$ gdb -q -batch -ex "set trace-commands on" \
-ex "set logging off" \
-ex "show logging file" \
-ex "set logging on" \
-ex "show logging file"
+set logging off
+show logging file
Future logs will be written to gdb.txt.
+set logging on
+show logging file
Currently logging to "gdb.txt".
...
After that commit we have instead:
...
+set logging off
+show logging file
The current logfile is "gdb.txt".
+set logging on
+show logging file
The current logfile is "gdb.txt".
...
Before the commit, whether logging is enabled or not can be deduced from the
output of the command. After the commit, the message is unified and it's no
longer clear whether logging is enabled or not.
Fix this by:
- adding a new command "show logging enabled"
- adding a corresponding new command "set logging enabled on/off"
- making the commands "set logging on/off" deprecated aliases of the
"set logging enabled on/off" command.
Update the docs and testsuite to use "set logging enabled". Mention the new
and deprecated commands in NEWS.
Tested on x86_64-linux.
The documentation for the examining memory command x contains an example:
...
You can also specify a negative repeat count to examine memory backward from
the given address. For example, 'x/-3uh 0x54320' prints three halfwords (h)
at 0x54314, 0x54328, and 0x5431c.
...
The 0x54328 looks like a typo, which was intended to be 0x54318.
But the series uses a 4-byte distance, while the halfword size used in the
command means a 2-byte distance, so the series should be:
...
0x5431a, 0x5431c, and 0x5431e.
...
Fix this by updating the addresses in the example accordingly.
Reported here ( https://sourceware.org/pipermail/gdb/2021-November/049784.html
).
As discussed here [1], do some re-work in the "set debuginfod commands".
First, use "set debuginfod enabled on/off/ask" instead of "set
debuginfod on/off/ask". This is more MI-friendly, and it gives an
output that makes more sense in "info set", for example.
Then, make the show commands not call "error" when debuginfod support is
not compiled in. This makes the commands "show" and "show debuginfod"
stop early, breaking gdb.base/default.exp:
Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/default.exp ...
FAIL: gdb.base/default.exp: info set
FAIL: gdb.base/default.exp: show
- Make the "debuginfod enabled" setting default to "off" when debuginfod
support is not compiled in, and "ask" otherwise.
- Make the setter of "debuginfod enabled" error out when debuginfod
support is not compiled in, so that "debuginfod enabled" will always
remain "off" in that case.
- Make the setter of "debuginfod verbose" work in any case. I don't
see the harm in letting the user change that setting, since the user will
hit an error if they try to enable the use of debuginfod.
- I would do the same for the "debuginfod urls" setter, but because
this one needs to see the DEBUGINFOD_URLS_ENV_VAR macro, provided by
libdebuginfod, I made that one error out as well if debuginfod
support is not compiled it (otherwise, I would have left it like
"debuginfod verbose". Alternatively, we could hard-code
"DEBUGINFOD_URLS" in the code (in fact, it was prior to this patch,
but I think it was an oversight, as other spots use
DEBUGINFOD_URLS_ENV_VAR), or use a dummy string to store the setting,
but I don't really see the value in that.
Rename debuginfod_enable to debuginfod_enabled, just so it matches the
setting name.
[1] https://sourceware.org/pipermail/gdb-patches/2021-October/182937.html
Change-Id: I45fdb2993f668226a5639228951362b7800f09d5
Co-Authored-By: Aaron Merey <amerey@redhat.com>
The "set index-cache" command is used at the same time as a prefix
command (prefix for "set index-cache directory", for example), and a
boolean setting for turning the index-cache on and off. Even though I
did introduce that, I now don't think it's a good idea to do something
non-standard like this.
First, there's no dedicated CLI command to show whether the index-cache
is enabled, so it has to be custom output in the "show index-cache
handler". Also, it means there's no good way a MI frontend can find out
if the index-cache is enabled. "-gdb-show index-cache" doesn't show it
in the MI output record:
(gdb) interpreter-exec mi "-gdb-show index-cache"
~"\n"
~"The index cache is currently disabled.\n"
^done,showlist={option={name="directory",value="/home/simark/.cache/gdb"}}
Fix this by introducing "set/show index-cache enabled on/off", regular
boolean setting commands. Keep commands "set index-cache on" and "set
index-cache off" as deprecated aliases of "set index-cache enabled",
with respectively the default arguments "on" and "off".
Update tests using "set index-cache on/off" to use the new command.
Update the regexps in gdb.base/maint.exp to figure out whether the
index-cache is enabled or not. Update the doc to mention the new
commands.
Change-Id: I7d5aaaf7fd22bf47bd03e0023ef4fbb4023b37b3
Updated manpages to be consistent with help information provided by the
binary. The main changes are:
* Making all long-form options have '--', instead of a single '-';
* added most of the missing options to the manpage;
* removed the information about using '+' instead of '-', since it
doesn't seem to be supported anymore.
This also fixes 2 upstream bugs:
* https://sourceware.org/bugzilla/show_bug.cgi?id=23965; by adding
--args to the manpage
* https://sourceware.org/bugzilla/show_bug.cgi?id=10619; by adding the
double dashes
Add section describing GDB's usage of debuginfod.
Refer to this new section in the description of the '--with-debuginfod'
configure option.
Mention debuginfod in the 'Separate Debug Files' section.
This adds a new Python function, gdb.Architecture.integer_type, which
can be used to look up an integer type of a given size and
signed-ness. This is useful to avoid dependency on debuginfo when a
particular integer type would be useful.
v2 moves this to be a method on gdb.Architecture and addresses other
review comments.
I saw the new -verbose switch to "maint selftests" and thought it would
be nice for it to use the option framework. For example, that makes
having completion easy. It's not that high value, given this is a
maintenance command, but I had never used the framework myself, so it
was a good way to practice.
This patch also adds the "maint set/show selftest verbose" setting. It
would be possible to use option framework without adding the setting,
but using the framework makes adding the option almost trivial, so I
thought why not.
Change-Id: I6687faa0713ff3da60b398253211777100094144
In the docs about print inferior-events we read:
...
By default, these messages will not be printed.
...
That used to be the case, but is no longer so since commit f67c0c9171 "Enable
'set print inferior-events' and improve detach/fork/kill/exit messages".
Fix this by updating the docs.
Add a new function to the Python API, gdb.architecture_names(). This
function returns a list containing all of the supported architecture
names within the current build of GDB.
The values returned in this list are all of the possible values that
can be returned from gdb.Architecture.name().
The documentation for 'show print elements' contains the line:
If the number is 0, then the printing is unlimited.
However, this line is now out of date as can be seen by this GDB
session:
(gdb) set print elements 0
(gdb) show print elements
Limit on string chars or array elements to print is unlimited.
The value 0 does indeed mean unlimited, and this is described in the
'set print elements' section, however, for 'show print elements' the
user will never see the value 0, so lets just remove that bit from the
docs.
Add a new event, gdb.events.gdb_exiting, which is called once GDB
decides it is going to exit.
This event is not triggered in the case that GDB performs a hard
abort, for example, when handling an internal error and the user
decides to quit the debug session, or if GDB hits an unexpected,
fatal, signal.
This event is triggered if the user just types 'quit' at the command
prompt, or if GDB is run with '-batch' and has processed all of the
required commands.
The new event type is gdb.GdbExitingEvent, and it has a single
attribute exit_code, which is the value that GDB is about to exit
with.
The event is triggered before GDB starts dismantling any of its own
internal state, so, my expectation is that most Python calls should
work just fine at this point.
When considering this functionality I wondered about using the
'atexit' Python module. However, this is triggered when the Python
environment is shut down, which is done from a final cleanup. At
this point we don't know for sure what other GDB state has already
been cleaned up.
The test gdb.python/py-events.exp sets up a handler for the gdb.exited
event. Unfortunately the handler is slightly broken, it assumes that
the exit_code attribute will always be present. This is not always
the case.
In a later commit I am going to add more tests to py-events.exp test
script, and in so doing I expose the bug in our handling of gdb.exited
events.
Just to be clear, GDB itself is fine, it is the test that is not
written correctly according to the Python Events API.
So, in this commit I fix the Python code in the test, and extend the
test case to exercise more paths through the Python code.
Additionally, I noticed that the gdb.exited event is used as an
example in the documentation for how to write an event handler.
Unfortunately the same bug that we had in our test was also present in
the example code in the manual.
So I've fixed that too.
After this commit there is no functional change to GDB.
With this commit:
commit 91f2597bd2
Date: Thu Aug 12 18:24:59 2021 +0100
gdb: print backtrace for internal error/warning
I included some references to 'stderr', which, it was pointed out,
would be better written as 'standard error stream'. See:
https://sourceware.org/pipermail/gdb-patches/2021-September/182225.html
This commit replaces the two instances of 'stderr' that I introduced.
This commit builds on previous work to allow GDB to print a backtrace
of itself when GDB encounters an internal-error or internal-warning.
This fixes PR gdb/26377.
There's not many places where we call internal_warning, and I guess in
most cases the user would probably continue their debug session. And
so, in order to avoid cluttering up the output, by default, printing
of a backtrace is off for internal-warnings.
In contrast, printing of a backtrace is on by default for
internal-errors, as I figure that in most cases hitting an
internal-error is going to be the end of the debug session.
Whether a backtrace is printed or not can be controlled with the new
settings:
maintenance set internal-error backtrace on|off
maintenance show internal-error backtrace
maintenance set internal-warning backtrace on|off
maintenance show internal-warning backtrace
Here is an example of what an internal-error now looks like with the
backtrace included:
(gdb) maintenance internal-error blah
../../src.dev-3/gdb/maint.c:82: internal-error: blah
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
0x5c61ca gdb_internal_backtrace_1
../../src.dev-3/gdb/bt-utils.c:123
0x5c626d _Z22gdb_internal_backtracev
../../src.dev-3/gdb/bt-utils.c:165
0xe33237 internal_vproblem
../../src.dev-3/gdb/utils.c:393
0xe33539 _Z15internal_verrorPKciS0_P13__va_list_tag
../../src.dev-3/gdb/utils.c:470
0x1549652 _Z14internal_errorPKciS0_z
../../src.dev-3/gdbsupport/errors.cc:55
0x9c7982 maintenance_internal_error
../../src.dev-3/gdb/maint.c:82
0x636f57 do_simple_func
../../src.dev-3/gdb/cli/cli-decode.c:97
.... snip, lots more backtrace lines ....
---------------------
../../src.dev-3/gdb/maint.c:82: internal-error: blah
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) y
This is a bug, please report it. For instructions, see:
<https://www.gnu.org/software/gdb/bugs/>.
../../src.dev-3/gdb/maint.c:82: internal-error: blah
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) n
My hope is that this backtrace might make it slightly easier to
diagnose GDB issues if all that is provided is the console output, I
find that we frequently get reports of an assert being hit that is
located in pretty generic code (frame.c, value.c, etc) and it is not
always obvious how we might have arrived at the assert.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26377
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.
The print_one_insn selftest in gdb/disasm-selftests.c contains:
...
/* If you want to see the disassembled instruction printed to gdb_stdout,
set verbose to true. */
static const bool verbose = false;
...
Make this parameter available in the maint selftest command using a new option
-verbose, such that we can do:
...
(gdb) maint selftest -verbose print_one_insn
...
Tested on x86_64-linux.
For some reason these two weren't added to the list when they were orginally
added to GDB.
gdb/doc/ChangeLog:
2021-09-21 Felix Willgerodt <felix.willgerodt@intel.com>
* gdb.texinfo (Predefined Target Types): Mention ieee_half and bfloat16.
The @inforef command is deprecated, and @xref does the samething.
Also had to update the text capitalization to match current manual.
Verified that info & HTML links work.
The guile API has (history-append! <value>) to add values into GDB's
history list. There is currently no equivalent in the Python API.
This commit adds gdb.add_history(<value>) to the Python API, this
function takes <value> a gdb.Value (or anything that can be passed to
the constructor of gdb.Value), and adds the value it represents to
GDB's history list. The index of the newly added value is returned.
