Commit graph

3010 commits

Author SHA1 Message Date
Andrew Burgess
0642912e83 gdb/python: allow Value.format_string to return styled output
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.
2022-02-07 16:52:47 +00:00
Tankut Baris Aktemur
61fb73769a gdb: add the 'set/show suppress-cli-notifications' command
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
2022-02-07 08:26:56 +01:00
Andrew Burgess
026fbfa60e gdb/doc: update docs for 'info win' and 'winheight' commands
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.
2022-02-06 12:29:56 +00:00
Andrew Burgess
bbea680797 gdb/python: improve the auto help text for gdb.Parameter
This commit attempts to improve the help text that is generated for
gdb.Parameter objects when the user fails to provide their own
documentation.

Documentation for a gdb.Parameter is currently pulled from two
sources: the class documentation string, and the set_doc/show_doc
class attributes.  Thus, a fully documented parameter might look like
this:

  class Param_All (gdb.Parameter):
     """This is the class documentation string."""

     show_doc = "Show the state of this parameter"
     set_doc = "Set the state of this parameter"

     def get_set_string (self):
        val = "on"
        if (self.value == False):
           val = "off"
        return "Test Parameter has been set to " + val

     def __init__ (self, name):
        super (Param_All, self).__init__ (name, gdb.COMMAND_DATA, gdb.PARAM_BOOLEAN)
        self._value = True

  Param_All ('param-all')

Then in GDB we see this:

  (gdb) help set param-all
  Set the state of this parameter
  This is the class documentation string.

Which is fine.  But, if the user skips both of the documentation parts
like this:

  class Param_None (gdb.Parameter):

     def get_set_string (self):
        val = "on"
        if (self.value == False):
           val = "off"
        return "Test Parameter has been set to " + val

     def __init__ (self, name):
        super (Param_None, self).__init__ (name, gdb.COMMAND_DATA, gdb.PARAM_BOOLEAN)
        self._value = True

  Param_None ('param-none')

Now in GDB we see this:

  (gdb) help set param-none
  This command is not documented.
  This command is not documented.

That's not great, the duplicated text looks a bit weird.  If we drop
different parts we get different results.  Here's what we get if the
user drops the set_doc and show_doc attributes:

  (gdb) help set param-doc
  This command is not documented.
  This is the class documentation string.

That kind of sucks, we say it's undocumented, then proceed to print
the documentation.  Finally, if we drop the class documentation but
keep the set_doc and show_doc:

  (gdb) help set param-set-show
  Set the state of this parameter
  This command is not documented.

That seems OK.

So, I think there's room for improvement.

With this patch, for the four cases above we now see this:

  # All values provided by the user, no change in this case:
  (gdb) help set param-all
  Set the state of this parameter
  This is the class documentation string.

  # Nothing provided by the user, the first string is now different:
  (gdb) help set param-none
  Set the current value of 'param-none'.
  This command is not documented.

  # Only the class documentation is provided, the first string is
  # changed as in the previous case:
  (gdb) help set param-doc
  Set the current value of 'param-doc'.
  This is the class documentation string.

  # Only the set_doc and show_doc are provided, this case is unchanged
  # from before the patch:
  (gdb) help set param-set-show
  Set the state of this parameter
  This command is not documented.

The one place where this change might be considered a negative is when
dealing with prefix commands.  If we create a prefix command but don't
supply the set_doc / show_doc strings, then this is what we saw before
my patch:

  (gdb) python Param_None ('print param-none')
  (gdb) help set print
  set print, set pr, set p
  Generic command for setting how things print.

  List of set print subcommands:

  ... snip ...
  set print param-none -- This command is not documented.
  ... snip ...

And after my patch:

  (gdb) python Param_None ('print param-none')
  (gdb) help set print
  set print, set pr, set p
  Generic command for setting how things print.

  List of set print subcommands:

  ... snip ...
  set print param-none -- Set the current value of 'print param-none'.
  ... snip ...

This seems slightly less helpful than before, but I don't think its
terrible.

Additionally, I've changed what we print when the get_show_string
method is not provided in Python.

Back when gdb.Parameter was first added to GDB, we didn't provide a
show function when registering the internal command object within
GDB.  As a result, GDB would make use of its "magic" mangling of the
show_doc string to create a sentence that would display the current
value (see deprecated_show_value_hack in cli/cli-setshow.c).

However, when we added support for the get_show_string method to
gdb.Parameter, there was an attempt to maintain backward compatibility
by displaying the show_doc string with the current value appended, see
get_show_value in py-param.c.  Unfortunately, this isn't anywhere
close to what deprecated_show_value_hack does, and the results are
pretty poor, for example, this is GDB before my patch:

  (gdb) show param-none
  This command is not documented. off

I think we can all agree that this is pretty bad.

After my patch, we how show this:

  (gdb) show param-none
  The current value of 'param-none' is "off".

Which at least is a real sentence, even if it's not very informative.

This patch does change the way that the Python API behaves slightly,
but only in the cases when the user has missed providing GDB with some
information.  In most cases I think the new behaviour is a lot better,
there's the one case (noted above) which is a bit iffy, but I think is
still OK.

I've updated the existing gdb.python/py-parameter.exp test to cover
the modified behaviour.

Finally, I've updated the documentation to (I hope) make it clearer
how the various bits of help text come together.
2022-01-26 22:00:20 +00:00
Andrew Burgess
30a87e90be gdb/python: add gdb.history_count function
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.
2022-01-26 21:58:12 +00:00
Tom Tromey
b583c328e7 Add a way to temporarily set a gdb parameter from Python
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
2022-01-26 06:49:51 -07:00
Andrew Burgess
965c919f98 gdb/doc: improve description for Window.click on Python TUI windows
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.
2022-01-24 15:33:55 +00:00
Andrew Burgess
b13d7831eb gdb/doc: fill in two missing @r
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.
2022-01-21 12:49:48 +00:00
Andrew Burgess
61671e9792 gdb/python: add gdb.host_charset function
We already have gdb.target_charset and gdb.target_wide_charset.  This
commit adds gdb.host_charset along the same lines.
2022-01-12 16:00:07 +00:00
Andrew Burgess
643b126809 gdb: add 'maint set/show gnu-source-highlight enabled' command
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.
2022-01-12 11:33:31 +00:00
Andrew Burgess
3937077888 gdb: new 'maint flush source-cache' command
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.
2022-01-12 11:19:48 +00:00
Andrew Burgess
8864ef428d gdb: rename lin-lwp to linux-nat in set/show debug
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.
2022-01-12 10:51:03 +00:00
Andrew Burgess
d50964864b gdb/doc: shorten some source lines, and prevent some line breaks
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.
2022-01-07 14:42:35 +00:00
Andrew Burgess
8af9b8009b gdb/doc: Remove (...) around guile procedure names in @deffn lines
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.
2022-01-07 14:38:39 +00:00
Joel Brobecker
2da76ea456 Manual copyright year update of various GDB files
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.
2022-01-01 19:13:23 +04:00
Joel Brobecker
4a94e36819 Automatic Copyright Year update after running gdb/copyright.py
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.
2022-01-01 19:13:23 +04:00
Lancelot SIX
003aae0762 gdb: Copy inferior properties in clone-inferior
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
2021-12-29 03:27:38 -05:00
Andrew Burgess
042574aa6e gdb/doc: add some index entries relating to mi-async setting
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.
2021-12-22 15:42:44 +00:00
Andrew Burgess
5b0a3d6242 gdb: add threads debugging switch
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`).
2021-12-22 15:02:02 +00:00
Enze Li
fa8f0a0ff0 gdb: add "exit" command as an alias for "quit"
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
2021-12-18 15:19:12 +04:00
Andrew Burgess
2988a36005 gdb/python: Use tp_init instead of tp_new to setup gdb.Value
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.
2021-12-08 13:38:11 +00:00
Tom Tromey
bc75fb44c5 Implement 'task apply'
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.
2021-12-02 08:58:22 -07:00
Tom Tromey
8a18382f94 Add "task" keyword to the "watch" command
Breakpoints in gdb can be made specific to an Ada task using the
"task" qualifier.  This patch applies this same idea to watchpoints.
2021-12-02 08:58:22 -07:00
Andrew Burgess
24b2de7b77 gdb/python: add gdb.RemoteTargetConnection.send_packet
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.
2021-11-30 12:10:40 +00:00
Andrew Burgess
e5b176f25f gdb: make packet_command function available outside remote.c
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.
2021-11-30 12:10:40 +00:00
Andrew Burgess
0e3b7c25ee gdb/python: introduce gdb.TargetConnection object type
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'.
2021-11-30 12:10:33 +00:00
Tom de Vries
6ff9675421 [gdb/cli] Add "set logging enabled", deprecate "set logging on/off"
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.
2021-11-25 07:49:16 +01:00
Tom de Vries
8ba97c1904 [gdb/doc] Fix negative repeat count examining memory example
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
).
2021-11-18 19:22:51 +01:00
Simon Marchi
333f35b631 gdb: rework "set debuginfod" commands
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>
2021-11-15 21:47:27 -05:00
Simon Marchi
7bc5c369fa gdb: introduce "set index-cache enabled", deprecate "set index-cache on/off"
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
2021-11-04 15:48:59 -04:00
Bruno Larsen
2047d95b89 [gdb/doc]: Updated manpages to be consistent with help
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
2021-11-01 10:47:19 -03:00
Aaron Merey
3ea44f2129 gdb.texinfo: Expand documentation for debuginfod
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.
2021-10-29 20:58:21 -04:00
Tom Tromey
d3771fe234 Add gdb.Architecture.integer_type Python function
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.
2021-10-29 07:52:31 -06:00
Enze Li
91b7c7e522 Document "memory-tag-violations".
* gdb/doc/gdb.texinfo: (Data): Document	'-memory-tag-violations'.
 (Command Options): Update the example.
2021-10-29 13:31:37 +03:00
Simon Marchi
a1ff87d77c gdb: add "maint set/show selftest verbose" commands and use process_options
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
2021-10-28 10:48:16 -04:00
Tom de Vries
a4b0231e17 [gdb/doc] Fix print inferior-events default
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.
2021-10-26 10:45:08 +02:00
Andrew Burgess
8b87fbe6bb gdb/python: new gdb.architecture_names function
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().
2021-10-22 13:42:49 +01:00
Srinath Parvathaneni
ae66a8f19e [ARM] Add support for M-profile MVE extension
This patch adds support for the M-profile MVE extension, which includes the
following:

- New M-profile XML feature m-profile-mve
- MVE vector predication status and control register (VPR)
- p0 pseudo register (contained in the VPR)
- q0 ~ q7 pseudo vector registers
- New feature bits
- Documentation update

Pseudo register p0 is the least significant bits of vpr and can be accessed
as $p0 or displayed through $vpr.  For more information about the register
layout, please refer to [1].

The q0 ~ q7 registers map back to the d0 ~ d15 registers, two d registers
per q register.

The register dump looks like this:

(gdb) info reg all
r0             0x0                 0
r1             0x0                 0
r2             0x0                 0
r3             0x0                 0
r4             0x0                 0
r5             0x0                 0
r6             0x0                 0
r7             0x0                 0
r8             0x0                 0
r9             0x0                 0
r10            0x0                 0
r11            0x0                 0
r12            0x0                 0
sp             0x0                 0x0 <__Vectors>
lr             0xffffffff          -1
pc             0xd0c               0xd0c <Reset_Handler>
xpsr           0x1000000           16777216
d0             0                   (raw 0x0000000000000000)
d1             0                   (raw 0x0000000000000000)
d2             0                   (raw 0x0000000000000000)
d3             0                   (raw 0x0000000000000000)
d4             0                   (raw 0x0000000000000000)
d5             0                   (raw 0x0000000000000000)
d6             0                   (raw 0x0000000000000000)
d7             0                   (raw 0x0000000000000000)
d8             0                   (raw 0x0000000000000000)
d9             0                   (raw 0x0000000000000000)
d10            0                   (raw 0x0000000000000000)
d11            0                   (raw 0x0000000000000000)
d12            0                   (raw 0x0000000000000000)
d13            0                   (raw 0x0000000000000000)
d14            0                   (raw 0x0000000000000000)
d15            0                   (raw 0x0000000000000000)
fpscr          0x0                 0
vpr            0x0                 [ P0=0 MASK01=0 MASK23=0 ]
s0             0                   (raw 0x00000000)
s1             0                   (raw 0x00000000)
s2             0                   (raw 0x00000000)
s3             0                   (raw 0x00000000)
s4             0                   (raw 0x00000000)
s5             0                   (raw 0x00000000)
s6             0                   (raw 0x00000000)
s7             0                   (raw 0x00000000)
s8             0                   (raw 0x00000000)
s9             0                   (raw 0x00000000)
s10            0                   (raw 0x00000000)
s11            0                   (raw 0x00000000)
s12            0                   (raw 0x00000000)
s13            0                   (raw 0x00000000)
s14            0                   (raw 0x00000000)
s15            0                   (raw 0x00000000)
s16            0                   (raw 0x00000000)
s17            0                   (raw 0x00000000)
s18            0                   (raw 0x00000000)
s19            0                   (raw 0x00000000)
s20            0                   (raw 0x00000000)
s21            0                   (raw 0x00000000)
s22            0                   (raw 0x00000000)
s23            0                   (raw 0x00000000)
s24            0                   (raw 0x00000000)
s25            0                   (raw 0x00000000)
s26            0                   (raw 0x00000000)
s27            0                   (raw 0x00000000)
s28            0                   (raw 0x00000000)
s29            0                   (raw 0x00000000)
s30            0                   (raw 0x00000000)
s31            0                   (raw 0x00000000)
q0             {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}}
q1             {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}}
q2             {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}}
q3             {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}}
q4             {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}}
q5             {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}}
q6             {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}}
q7             {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}}
p0             0x0                 0

Built and regtested with a simulator.

[1] https://developer.arm.com/documentation/ddi0553/bn

Co-Authored-By: Luis Machado <luis.machado@linaro.org>
2021-10-11 16:03:56 -03:00
Andrew Burgess
24616c1995 gdb/doc: improve 'show print elements' description
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.
2021-10-06 14:36:23 +01:00
Andrew Burgess
b1f0f28418 gdb/python: add a new gdb_exiting event
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.
2021-10-05 10:05:40 +01:00
Andrew Burgess
1cb56ad3f3 gdb/python: update events test to handle missing exit_code
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.
2021-10-05 10:05:40 +01:00
Andrew Burgess
4180173142 gdb/doc: use 'standard error stream' instead of 'stderr' in some places
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.
2021-09-29 09:25:03 +01:00
Andrew Burgess
91f2597bd2 gdb: print backtrace for internal error/warning
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
2021-09-28 12:21:22 +01:00
Andrew Burgess
fde1a9a3ee gdb: add setting to disable reading source code files
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.
2021-09-27 11:31:35 +01:00
Tom de Vries
479209dd4f [gdb] Add maint selftest -verbose option
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.
2021-09-22 11:47:50 +02:00
Felix Willgerodt
be24dba6f1 gdb, doc: Add ieee_half and bfloat16 to list of predefined target types.
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.
2021-09-21 10:14:36 +02:00
Mike Frysinger
034ce7b42a gdb: manual: update @inforef to @xref
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.
2021-09-19 02:20:34 -04:00
Mike Frysinger
0ffd31f044 gdb: manual: fix werrors typo 2021-09-16 03:27:56 -04:00
Tom de Vries
3d53d4603e [gdb/doc] Fix typo in maint selftest entry
Fix typo "will by" -> "will be".
2021-09-15 11:46:57 +02:00
Andrew Burgess
540bf37b25 gdb/python: new function to add values into GDB's history
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.
2021-09-07 10:54:07 +01:00