Commit graph

1188 commits

Author SHA1 Message Date
Tom Tromey
992aeed80b Use ui_out_redirect_pop in more places
This changes ui_out_redirect_pop to also perform the redirection, and
then updates several sites to use this, rather than explicit
redirects.
2022-08-31 11:03:39 -06:00
Tom Tromey
2d83dd6939 Fix flush for sys.stderr
GDB overwrites Python's sys.stdout and sys.stderr, but does not
properly implement the 'flush' method -- it only ever will flush
stdout.  This patch fixes the bug.  I couldn't find a straightforward
way to write a test for this.
2022-08-30 11:49:48 -06:00
Tom Tromey
bdc8cfc1e4 Fix crash in gdbpy_parse_register_id
I noticed that gdbpy_parse_register_id would assert if passed a Python
object of a type it was not expecting.  The included test case shows
this crash.  This patch fixes the problem and also changes
gdbpy_parse_register_id to be more "Python-like" -- it always ensures
the Python error is set when it fails, and the callers now simply
propagate the existing exception.
2022-08-21 08:03:42 -06:00
Tom Tromey
cb275538db Use registry in gdbarch
gdbarch implements its own registry-like approach.  This patch changes
it to instead use registry.h.  It's a rather large patch but largely
uninteresting -- it's mostly a straightforward conversion from the old
approach to the new one.

The main benefit of this change is that it introduces type safety to
the gdbarch registry.  It also removes a bunch of code.

One possible drawback is that, previously, the gdbarch registry
differentiated between pre- and post-initialization setup.  This
doesn't seem very important to me, though.
2022-08-04 13:28:04 -06:00
Tom Tromey
98badbfdc2 Use gdb_bfd_ref_ptr in objfile
This changes struct objfile to use a gdb_bfd_ref_ptr.  In addition to
removing some manual memory management, this fixes a use-after-free
that was introduced by the registry rewrite series.  The issue there
was that, in some cases, registry shutdown could refer to memory that
had already been freed.  This help fix the bug by delaying the
destruction of the BFD reference (and thus the per-bfd object) until
after the registry has been shut down.
2022-08-03 13:26:58 -06:00
Tom Tromey
08b8a139c9 Rewrite registry.h
This rewrites registry.h, removing all the macros and replacing it
with relatively ordinary template classes.  The result is less code
than the previous setup.  It replaces large macros with a relatively
straightforward C++ class, and now manages its own cleanup.

The existing type-safe "key" class is replaced with the equivalent
template class.  This approach ended up requiring relatively few
changes to the users of the registry code in gdb -- code using the key
system just required a small change to the key's declaration.

All existing users of the old C-like API are now converted to use the
type-safe API.  This mostly involved changing explicit deletion
functions to be an operator() in a deleter class.

The old "save/free" two-phase process is removed, and replaced with a
single "free" phase.  No existing code used both phases.

The old "free" callbacks took a parameter for the enclosing container
object.  However, this wasn't truly needed and is removed here as
well.
2022-07-28 14:16:50 -06:00
Tom Tromey
bde539c2f9 Change allocation of type-copying hash table
When an objfile is destroyed, types that are still in use and
allocated on that objfile are copied.  A temporary hash map is created
during this process, and it is allocated on the destroyed objfile's
obstack -- which normally is fine, as that is going to be destroyed
shortly anyway.

However, this approach requires that the objfile be passed to registry
destruction, and this won't be possible in the rewritten registry.
This patch changes the copied type hash table to simply use the heap
instead.  It also removes the 'objfile' parameter from
copy_type_recursive, to make this all more clear.

This patch also fixes an apparent bug in copy_type_recursive.
Previously it was copying the dynamic property list to the dying
objfile's obstack:

-      = copy_dynamic_prop_list (&objfile->objfile_obstack,

However I think this is incorrect -- that obstack is about to be
destroyed.
2022-07-28 14:16:50 -06:00
Simon Farre
e5213e2c85 gdb/python: Add BreakpointLocation type
PR python/18385

v7:
This version addresses the issues pointed out by Tom.

Added nullchecks for Python object creations.

Changed from using PyLong_FromLong to the gdb_py-versions.

Re-factored some code to make it look more cohesive.

Also added the more safe Python reference count decrement PY_XDECREF,
even though the BreakpointLocation type is never instantiated by the
user (explicitly documented in the docs) decrementing < 0 is made
impossible with the safe call.

Tom pointed out that using the policy class explicitly to decrement a
reference counted object was not the way to go, so this has instead been
wrapped in a ref_ptr that handles that for us in blocpy_dealloc.

Moved macro from py-internal to py-breakpoint.c.

Renamed section at the bottom of commit message "Patch Description".

v6:
This version addresses the points Pedro gave in review to this patch.

Added the attributes `function`, `fullname` and `thread_groups`
as per request by Pedro with the argument that it more resembles the
output of the MI-command "-break-list".  Added documentation for these attributes.

Cleaned up left overs from copy+paste in test suite, removed hard coding
of line numbers where possible.

Refactored some code to use more c++-y style range for loops
wrt to breakpoint locations.

Changed terminology, naming was very inconsistent. Used a variety of "parent",
"owner". Now "owner" is the only term used, and the field in the
gdb_breakpoint_location_object now also called "owner".

v5:

Changes in response to review by Tom Tromey:
- Replaced manual INCREF/DECREF calls with
  gdbpy_ref ptrs in places where possible.
- Fixed non-gdb style conforming formatting
- Get parent of bploc increases ref count of parent.
- moved bploc Python definition to py-breakpoint.c

The INCREF of self in bppy_get_locations is due
to the individual locations holding a reference to
it's owner. This is decremented at de-alloc time.

The reason why this needs to be here is, if the user writes
for instance;

py loc = gdb.breakpoints()[X].locations[Y]

The breakpoint owner object is immediately going
out of scope (GC'd/dealloced), and the location
object requires it to be alive for as long as it is alive.

Thanks for your review, Tom!

v4:
Fixed remaining doc issues as per request
by Eli.

v3:
Rewritten commit message, shortened + reworded,
added tests.

Patch Description

Currently, the Python API lacks the ability to
query breakpoints for their installed locations,
and subsequently, can't query any information about them, or
enable/disable individual locations.

This patch solves this by adding Python type gdb.BreakpointLocation.
The type is never instantiated by the user of the Python API directly,
but is produced by the gdb.Breakpoint.locations attribute returning
a list of gdb.BreakpointLocation.

gdb.Breakpoint.locations:
The attribute for retrieving the currently installed breakpoint
locations for gdb.Breakpoint. Matches behavior of
the "info breakpoints" command in that it only
returns the last known or currently inserted breakpoint locations.

BreakpointLocation contains 7 attributes

6 read-only attributes:
owner: location owner's Python companion object
source: file path and line number tuple: (string, long) / None
address: installed address of the location
function: function name where location was set
fullname: fullname where location was set
thread_groups: thread groups (inferiors) where location was set.

1 writeable attribute:
enabled: get/set enable/disable this location (bool)

Access/calls to these, can all throw Python exceptions (documented in
the online documentation), and that's due to the nature
of how breakpoint locations can be invalidated
"behind the scenes", either by them being removed
from the original breakpoint or changed,
like for instance when a new symbol file is loaded, at
which point all breakpoint locations are re-created by GDB.
Therefore this patch has chosen to be non-intrusive:
it's up to the Python user to re-request the locations if
they become invalid.

Also there's event handlers that handle new object files etc, if a Python
user is storing breakpoint locations in some larger state they've
built up, refreshing the locations is easy and it only comes
with runtime overhead when the Python user wants to use them.

gdb.BreakpointLocation Python type
struct "gdbpy_breakpoint_location_object" is found in python-internal.h

Its definition, layout, methods and functions
are found in the same file as gdb.Breakpoint (py-breakpoint.c)

1 change was also made to breakpoint.h/c to make it possible
to enable and disable a bp_location* specifically,
without having its LOC_NUM, as this number
also can change arbitrarily behind the scenes.

Updated docs & news file as per request.

Testsuite: tests the .source attribute and the disabling of
individual locations.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18385


Change-Id: I302c1c50a557ad59d5d18c88ca19014731d736b0
2022-07-28 11:20:46 -06:00
Kevin Buettner
24d2cbc42c set/show python dont-write-bytecode fixes
GDB uses the environment variable PYTHONDONTWRITEBYTECODE to
determine whether or not to write the result of byte-compiling
python modules when the "python dont-write-bytecode" setting
is "auto".  Simon noticed that GDB's implementation doesn't
follow the Python documentation.

At present, GDB only checks for the existence of this environment
variable.  That is not sufficient though.  Regarding
PYTHONDONTWRITEBYTECODE, this document...

    https://docs.python.org/3/using/cmdline.html

...says:

    If this is set to a non-empty string, Python won't try to write
    .pyc files on the import of source modules.

This commit fixes GDB's handling of PYTHONDONTWRITEBYTECODE by adding
an empty string check.

This commit also corrects the set/show command documentation for
"python dont-write-bytecode".  The current doc was just a copy
of that for set/show python ignore-environment.

During his review of an earlier version of this patch, Eli Zaretskii
asked that the help text that I proposed for "set/show python
dont-write-bytecode" be expanded.  I've done that in addition to
clarifying the documentation of this option in the GDB manual.
2022-07-25 12:05:14 -07:00
Andrew Burgess
23aa2befce gdb/python: fix invalid use disassemble_info::stream
After this commit:

  commit 81384924cd
  Date:   Tue Apr 5 11:06:16 2022 +0100

      gdb: have gdb_disassemble_info carry 'this' in its stream pointer

The disassemble_info::stream field will no longer be a ui_file*.  That
commit failed to update one location in py-disasm.c though.

While running some tests using the Python disassembler API, I
triggered a call to gdbpy_disassembler::print_address_func, and, as I
had compiled GDB with the undefined behaviour sanitizer, GDB crashed
as the code currently (incorrectly) casts the stream field to be a
ui_file*.

In this commit I fix this error.

In order to test this case I had to tweak the existing test case a
little.  I also spotted some debug printf statements in py-disasm.py,
which I have removed.
2022-07-25 19:26:24 +01:00
Tom de Vries
5c3392f981 [gdb/python] Fix typo in test_python
Fix typo in ref_output_0 variable in test_python.

Tested by running the selftest on x86_64-linux with python 3.11.
2022-07-21 14:55:00 +02:00
Tom de Vries
c57ac51086 [gdb/python] Fix python selftest with python 3.11
With python 3.11 I noticed:
...
$ gdb -q -batch -ex "maint selftest python"
Running selftest python.
Self test failed: self-test failed at gdb/python/python.c:2246
Ran 1 unit tests, 1 failed
...

In more detail:
...
(gdb) p output
$5 = "Traceback (most recent call last):\n  File \"<string>\", line 0, \
  in <module>\nKeyboardInterrupt\n"
(gdb) p ref_output
$6 = "Traceback (most recent call last):\n  File \"<string>\", line 1, \
  in <module>\nKeyboardInterrupt\n"
...

Fix this by also allowing line number 0.

Tested on x86_64-linux.

This should hopefully fix buildbot builder gdb-rawhide-x86_64.
2022-07-21 14:04:41 +02:00
Kevin Buettner
0679db2966 Wrap python_write_bytecode with HAVE_PYTHON ifdef
This commit fixes a build error on machines lacking python headers
and/or libraries.
2022-07-20 17:12:08 -07:00
Kevin Buettner
fe587fc997 Handle Python 3.11 deprecation of PySys_SetPath and Py_SetProgramName
Python 3.11 deprecates PySys_SetPath and Py_SetProgramName.  The
PyConfig API replaces these and other functions.  This commit uses the
PyConfig API to provide equivalent functionality while also preserving
support for older versions of Python, i.e. those before Python 3.8.

A beta version of Python 3.11 is available in Fedora Rawhide.  Both
Fedora 35 and Fedora 36 use Python 3.10, while Fedora 34 still used
Python 3.9.  I've tested these changes on Fedora 34, Fedora 36, and
rawhide, though complete testing was not possible on rawhide due to
a kernel bug.  That being the case, I decided to enable the newer
PyConfig API by testing PY_VERSION_HEX against 0x030a0000.  This
corresponds to Python 3.10.

We could try to use the PyConfig API for Python versions as early as 3.8,
but I'm reluctant to do this as there may have been PyConfig related
bugs in earlier versions which have since been fixed.  Recent linux
distributions should have support for Python 3.10.  This should be
more than adequate for testing the new Python initialization code in
GDB.

Information about the PyConfig API as well as the motivation behind
deprecating the old interface can be found at these links:

https://github.com/python/cpython/issues/88279
https://peps.python.org/pep-0587/
https://docs.python.org/3.11/c-api/init_config.html

The v2 commit also addresses several problems that Simon found in
the v1 version.

In v1, I had used Py_DontWriteBytecodeFlag in the new initialization
code, but Simon pointed out that this global configuration variable
will be deprecated in Python 3.12.  This version of the patch no longer
uses Py_DontWriteBytecodeFlag in the new initialization code.
Additionally, both Py_DontWriteBytecodeFlag and Py_IgnoreEnvironmentFlag
will no longer be used when building GDB against Python 3.10 or higher.
While it's true that both of these global configuration variables are
deprecated in Python 3.12, it makes sense to disable their use for
gdb builds against 3.10 and higher since those are the versions for
which the PyConfig API is now being used by GDB.  (The PyConfig API
includes different mechanisms for making the same settings afforded
by use of the soon-to-be deprecated global configuration variables.)

Simon also noted that PyConfig_Clear() would not have be called for
one of the failure paths.  I've fixed that problem and also made the
rest of the "bail out" code more direct.  In particular,
PyConfig_Clear() will always be called, both for success and failure.

The v3 patch addresses some rebase conflicts related to module
initialization .  Commit 3acd9a692d ("Make 'import gdb.events' work")
uses PyImport_ExtendInittab instead of PyImport_AppendInittab.  That
commit also initializes a struct for each module to import.  Both the
initialization and the call to were moved ahead of the ifdefs to avoid
having to replicate (at least some of) the code three times in various
portions of the ifdefs.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28668
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29287
2022-07-20 12:14:17 -07:00
Tom Tromey
0b4fe76f95 Add gdb.free_objfile event registry
Currently, Python code can use event registries to detect when gdb
loads a new objfile, and when gdb clears the objfile list.  However,
there's no way to detect the removal of an objfile, say when the
inferior calls dlclose.

This patch adds a gdb.free_objfile event registry and arranges for an
event to be emitted in this case.
2022-07-18 11:25:34 -06:00
Tom Tromey
3028a2dbbf Add 'nibbles' to gdb.print_options
When I rebased and updated the print_options patch, I forgot to update
print_options to add the new 'nibbles' feature to the result.  This
patch fixes the oversight.  I'm checking this in.
2022-07-15 09:42:39 -06:00
Tom Tromey
72be9d6be7 Add 'summary' mode to Value.format_string
This adds a 'summary' mode to Value.format_string and to
gdb.print_options.  For the former, it lets Python code format values
using this mode.  For the latter, it lets a printer potentially detect
if it is being called in a backtrace with 'set print frame-arguments'
set to 'scalars'.

I considered adding a new mode here to let a pretty-printer see
whether it was being called in a 'backtrace' context at all, but I'm
not sure if this is really desirable.
2022-07-15 09:26:54 -06:00
Tom Tromey
c4a3dbaf11 Expose current 'print' settings to Python
PR python/17291 asks for access to the current print options.  While I
think this need is largely satisfied by the existence of
Value.format_string, it seemed to me that a bit more could be done.

First, while Value.format_string uses the user's settings, it does not
react to temporary settings such as "print/x".  This patch changes
this.

Second, there is no good way to examine the current settings (in
particular the temporary ones in effect for just a single "print").
This patch adds this as well.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17291
2022-07-15 09:25:33 -06:00
Tom Tromey
bf4d777d39 Run 'black' on gdb
Running 'black' on gdb fixed a couple of small issues.  This patch is
the result.
2022-07-15 07:55:32 -06:00
Tom Tromey
d19ca0b35c Accept gdb.Value in more Python APIs
PR python/27000 points out that gdb.block_for_pc will accept a Python
integer, but not a gdb.Value.  This patch corrects this oversight.

I looked at all uses of GDB_PY_LLU_ARG and fixed these up to use
get_addr_from_python instead.  I also looked at uses of GDB_PY_LL_ARG,
but those seemed relatively unlikely to be useful with a gdb.Value, so
I didn't change them.  My thinking here is that a Value will typically
come from inferior memory, and something like a line number is not too
likely to be found this way.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27000
2022-07-08 14:14:58 -06:00
Tom Tromey
fa17a68141 Handle bool specially in gdb.set_parameter
PR python/29217 points out that gdb.parameter will return bool values,
but gdb.set_parameter will not properly accept them.  This patch fixes
the problem by adding a special case to set_parameter.

I looked at a fix involving rewriting set_parameter in C++.  However,
this one is simpler.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29217
2022-07-08 13:56:56 -06:00
Tom Tromey
99298c958c Add gdb.Objfile.is_file attribute
Sometimes an objfile comes from memory and not from a file.  It can be
useful to be able to check this from Python, so this patch adds a new
"is_file" attribute.
2022-07-05 11:22:20 -06:00
Tom Tromey
3acd9a692d Make 'import gdb.events' work
Pierre-Marie noticed that, while gdb.events is a Python module, it
can't be imported.  This patch changes how this module is created, so
that it can be imported, while also ensuring that the module is always
visible, just as it was in the past.

This new approach required one non-obvious change -- when running
gdb.base/warning.exp, where --data-directory is intentionally not
found, the event registries can now be nullptr.  Consequently, this
patch probably also requires

    https://sourceware.org/pipermail/gdb-patches/2022-June/189796.html

Note that this patch obsoletes

    https://sourceware.org/pipermail/gdb-patches/2022-June/189797.html
2022-07-05 10:28:39 -06:00
Tom Tromey
c86acd3f18 Use PyBool_FromLong
I noticed a few spots that were explicitly creating new references to
Py_True or Py_False.  It's simpler here to use PyBool_FromLong, so
this patch changes all the places I found.
2022-06-23 09:27:30 -06:00
Enze Li
3f52a09075 gdb/python: Export nibbles to python layer
This patch makes it possible to allow Value.format_string() to return
nibbles output.

When we set the parameter of nibbles to True, we can achieve the
displaying binary values in groups of every four bits.

Here's an example:
  (gdb) py print (gdb.Value (1230).format_string (format='t', nibbles=True))
  0100 1100 1110
  (gdb)

Note that the parameter nibbles is only useful if format='t' is also used.

This patch also includes update to the relevant testcase and
documentation.

Tested on x86_64 openSUSE Tumbleweed.
2022-06-18 11:23:16 +08:00
Pedro Alves
709438c75a Convert location_spec_to_string to a method
This converts location_spec_to_string to a method of location_spec,
simplifying the code using it, as it no longer has to use
std::unique_ptr::get().

Change-Id: I621bdad8ea084470a2724163f614578caf8f2dd5
2022-06-17 09:58:49 +01:00
Pedro Alves
40d97ee21f Eliminate the two-level data structures behind location_specs
Currently, there's the location_spec hierarchy, and then some
location_spec subclasses have their own struct type holding all their
data fields.

I.e., there is this:

 location_spec
   explicit_location_spec
   linespec_location_spec
   address_location_spec
   probe_location_spec

and then these separate types:

  explicit_location
  linespec_location

where:

  explicit_location_spec
     has-a explicit_location
  linespec_location_spec
     has-a linespec_location

This patch eliminates explicit_location and linespec_location,
inlining their members in the corresponding location_spec type.

The location_spec subclasses were the ones currently defined in
location.c, so they are moved to the header.  Since the definitions of
the classes are now visible, we no longer need location_spec_deleter.

Some constructors that are used for cloning location_specs, like:

  explicit explicit_location_spec (const struct explicit_location *loc)

... were converted to proper copy ctors.

In the process, initialize_explicit_location is eliminated, and some
functions that returned the "data type behind a locspec", like
get_linespec_location are converted to downcast functions, like
as_linespec_location_spec.

Change-Id: Ia31ccef9382b25a52b00fa878c8df9b8cf2a6c5a
2022-06-17 09:55:39 +01:00
Pedro Alves
264f98902f event_location -> location_spec
Currently, GDB internally uses the term "location" for both the
location specification the user input (linespec, explicit location, or
an address location), and for actual resolved locations, like the
breakpoint locations, or the result of decoding a location spec to
SaLs.  This is expecially confusing in the breakpoints module, as
struct breakpoint has these two fields:

  breakpoint::location;
  breakpoint::loc;

"location" is the location spec, and "loc" is the resolved locations.

And then, we have a method called "locations()", which returns the
resolved locations as range...

The location spec type is presently called event_location:

  /* Location we used to set the breakpoint.  */
  event_location_up location;

and it is described like this:

  /* The base class for all an event locations used to set a stop event
     in the inferior.  */

  struct event_location
  {

and even that is incorrect...  Location specs are used for finding
actual locations in the program in scenarios that have nothing to do
with stop events.  E.g., "list" works with location specs.

To clean all this confusion up, this patch renames "event_location" to
"location_spec" throughout, and then all the variables that hold a
location spec, they are renamed to include "spec" in their name, like
e.g., "location" -> "locspec".  Similarly, functions that work with
location specs, and currently have just "location" in their name are
renamed to include "spec" in their name too.

Change-Id: I5814124798aa2b2003e79496e78f95c74e5eddca
2022-06-17 09:41:24 +01:00
Tom Tromey
9d741cbedb Check for listeners in emit_exiting_event
I noticed that emit_exiting_event does not check whether there are any
listeners before creating the event object.  All other event emitters
do this, so this patch updates this one as well.
2022-06-15 14:07:25 -06:00
Andrew Burgess
15e15b2d9c gdb/python: implement the print_insn extension language hook
This commit extends the Python API to include disassembler support.

The motivation for this commit was to provide an API by which the user
could write Python scripts that would augment the output of the
disassembler.

To achieve this I have followed the model of the existing libopcodes
disassembler, that is, instructions are disassembled one by one.  This
does restrict the type of things that it is possible to do from a
Python script, i.e. all additional output has to fit on a single line,
but this was all I needed, and creating something more complex would,
I think, require greater changes to how GDB's internal disassembler
operates.

The disassembler API is contained in the new gdb.disassembler module,
which defines the following classes:

  DisassembleInfo

      Similar to libopcodes disassemble_info structure, has read-only
  properties: address, architecture, and progspace.  And has methods:
  __init__, read_memory, and is_valid.

      Each time GDB wants an instruction disassembled, an instance of
  this class is passed to a user written disassembler function, by
  reading the properties, and calling the methods (and other support
  methods in the gdb.disassembler module) the user can perform and
  return the disassembly.

  Disassembler

      This is a base-class which user written disassemblers should
  inherit from.  This base class provides base implementations of
  __init__ and __call__ which the user written disassembler should
  override.

  DisassemblerResult

      This class can be used to hold the result of a call to the
  disassembler, it's really just a wrapper around a string (the text
  of the disassembled instruction) and a length (in bytes).  The user
  can return an instance of this class from Disassembler.__call__ to
  represent the newly disassembled instruction.

The gdb.disassembler module also provides the following functions:

  register_disassembler

      This function registers an instance of a Disassembler sub-class
  as a disassembler, either for one specific architecture, or, as a
  global disassembler for all architectures.

  builtin_disassemble

      This provides access to GDB's builtin disassembler.  A common
  use case that I see is augmenting the existing disassembler output.
  The user code can call this function to have GDB disassemble the
  instruction in the normal way.  The user gets back a
  DisassemblerResult object, which they can then read in order to
  augment the disassembler output in any way they wish.

      This function also provides a mechanism to intercept the
  disassemblers reads of memory, thus the user can adjust what GDB
  sees when it is disassembling.

The included documentation provides a more detailed description of the
API.

There is also a new CLI command added:

  maint info python-disassemblers

This command is defined in the Python gdb.disassemblers module, and
can be used to list the currently registered Python disassemblers.
2022-06-15 09:44:54 +01:00
Andrew Burgess
e4ae302562 gdb: add extension language print_insn hook
This commit is setup for the next commit.

In the next commit I will add a Python API to intercept the print_insn
calls within GDB, each print_insn call is responsible for
disassembling, and printing one instruction.  After the next commit it
will be possible for a user to write Python code that either wraps
around the existing disassembler, or even, in extreme situations,
entirely replaces the existing disassembler.

This commit does not add any new Python API.

What this commit does is put the extension language framework in place
for a print_insn hook.  There's a new callback added to 'struct
extension_language_ops', which is then filled in with nullptr for Python
and Guile.

Finally, in the disassembler, the code is restructured so that the new
extension language function ext_lang_print_insn is called before we
delegate to gdbarch_print_insn.

After this, the next commit can focus entirely on providing a Python
implementation of the new print_insn callback.

There should be no user visible change after this commit.
2022-06-15 09:44:54 +01:00
Andrew Burgess
8a0b60471a gdb/python: convert gdbpy_err_fetch to use gdbpy_ref
Convert the gdbpy_err_fetch class to make use of gdbpy_ref, this
removes the need for manual reference count management, and allows the
destructor to be removed.

There should be no functional change after this commit.

I think this cleanup is worth doing on its own, however, in a later
commit I will want to copy instances of gdbpy_err_fetch, and switching
to using gdbpy_ref means that I can rely on the default copy
constructor, without having to add one that handles the reference
counts, so this is good preparation for that upcoming change.
2022-06-15 09:44:54 +01:00
Tom Tromey
6d08aed3c9 Constify solib_name_from_address
I noticed that solib_name_from_address returned a non-const string,
but it's more appropriate to return const.  This patch implements
this.  Tested by rebuilding.
2022-06-07 07:21:26 -06:00
Tom Tromey
ca9aae53bd Remove obsolete Python 2 comment
I found a comment that referred to Python 2, but that is now obsolete
-- the code it refers to is gone.  I'm checking in this patch to
remove the comment.

There's a similar comment elsewhere, but I plan to remove that one in
another patch I'm going to submit shortly.
2022-06-05 10:11:37 -06:00
Tom Tromey
f5a0f5b503 Use bool for evregpy_no_listeners_p
I noticed that evregpy_no_listeners_p should return a bool.  This
patch makes this change.  I'm checking it in.
2022-06-03 10:35:30 -06:00
Tom Tromey
cec000ad60 ODR warning for "enum string_repr_result"
"enum string_repr_result" is defined in multiple .c files, causing ODR
warnings.  This patch renames the types.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
2022-06-02 09:04:45 -06:00
Tom Tromey
80fa4b2a60 Add gdb.current_language and gdb.Frame.language
This adds the gdb.current_language function, which can be used to find
the current language without (1) ever having the value "auto" or (2)
having to parse the output of "show language".

It also adds the gdb.Frame.language, which can be used to find the
language of a given frame.  This is normally preferable if one has a
Frame object handy.
2022-06-01 06:15:53 -06:00
Andrew Burgess
51e8dbe1fb gdb/python: improve formatting of help text for user defined commands
Consider this command defined in Python (in the file test-cmd.py):

  class test_cmd (gdb.Command):
    """
    This is the first line.
      Indented second line.
    This is the third line.
    """

    def __init__ (self):
      super ().__init__ ("test-cmd", gdb.COMMAND_OBSCURE)

    def invoke (self, arg, from_tty):
      print ("In test-cmd")

  test_cmd()

Now, within a GDB session:

  (gdb) source test-cmd.py
  (gdb) help test-cmd

    This is the first line.
      Indented second line.
    This is the third line.

  (gdb)

I think there's three things wrong here:

  1. The leading blank line,
  2. The trailing blank line, and
  3. Every line is indented from the left edge slightly.

The problem of course, is that GDB is using the Python doc string
verbatim as its help text.  While the user has formatted the help text
so that it appears clear within the .py file, this means that the text
appear less well formatted when displayed in the "help" output.

The same problem can be observed for gdb.Parameter objects in their
set/show output.

In this commit I aim to improve the "help" output for commands and
parameters.

To do this I have added gdbpy_fix_doc_string_indentation, a new
function that rewrites the doc string text following the following
rules:

  1. Leading blank lines are removed,
  2. Trailing blank lines are removed, and
  3. Leading whitespace is removed in a "smart" way such that the
  relative indentation of lines is retained.

With this commit in place the above example now looks like this:

  (gdb) source ~/tmp/test-cmd.py
  (gdb) help test-cmd
  This is the first line.
    Indented second line.
  This is the third line.
  (gdb)

Which I think is much neater.  Notice that the indentation of the
second line is retained.  Any blank lines within the help text (not
leading or trailing) will be retained.

I've added a NEWS entry to note that there has been a change in
behaviour, but I didn't update the manual.  The existing manual is
suitably vague about how the doc string is used, so I think the new
behaviour is covered just as well by the existing text.
2022-05-28 10:36:50 +01:00
Andrew Burgess
0e77ff2c86 gdb: use gdb::unique_xmalloc_ptr<char> for docs in cmdpy_init
Make use of gdb::unique_xmalloc_ptr<char> to hold the documentation
string in cmdpy_init (when creating a custom GDB command in Python).
I think this is all pretty straight forward, the only slight weirdness
is the removal of the call to free toward the end of this function.

Prior to this commit, if an exception was thrown after the GDB command
was created then we would (I think) end up freeing the documentation
string even though the command would remain registered with GDB, which
would surely lead to undefined behaviour.

After this commit we release the doc string at the point that we hand
it over to the command creation routines.  If we throw _after_ the
command has been created within GDB then the doc string will be left
live.  If we throw during the command creation itself (either from
add_prefix_cmd or add_cmd) then it is up to those functions to free
the doc string (I suspect we don't, but I think in general the
commands are pretty bad at cleaning up after themselves, so I don't
think this is a huge problem).
2022-05-28 10:36:50 +01:00
Pedro Alves
74421c0bc8 Rename base_breakpoint -> code_breakpoint
Even after the previous patches reworking the inheritance of several
breakpoint types, the present breakpoint hierarchy looks a bit
surprising, as we have "breakpoint" as the superclass, and then
"base_breakpoint" inherits from "breakpoint".  Like so, simplified:

   breakpoint
       base_breakpoint
          ordinary_breakpoint
	  internal_breakpoint
	  momentary_breakpoint
	  ada_catchpoint
	  exception_catchpoint
       tracepoint
       watchpoint
       catchpoint
	  exec_catchpoint
	  ...

The surprising part to me is having "base_breakpoint" being a subclass
of "breakpoint".  I'm just refering to naming here -- I mean, you'd
expect that it would be the top level baseclass that would be called
"base".

Just flipping the names of breakpoint and base_breakpoint around
wouldn't be super great for us, IMO, given we think of every type of
*point as a breakpoint at the user visible level.  E.g., "info
breakpoints" shows watchpoints, tracepoints, etc.  So it makes to call
the top level class breakpoint.

Instead, I propose renaming base_breakpoint to code_breakpoint.  The
previous patches made sure that all code breakpoints inherit from
base_breakpoint, so it's fitting.  Also, "code breakpoint" contrasts
nicely with a watchpoint also being typically known as a "data
breakpoint".

After this commit, the resulting hierarchy looks like:

   breakpoint
       code_breakpoint
          ordinary_breakpoint
	  internal_breakpoint
	  momentary_breakpoint
	  ada_catchpoint
	  exception_catchpoint
       tracepoint
       watchpoint
       catchpoint
	  exec_catchpoint
	  ...

... which makes a lot more sense to me.

I've left this patch as last in the series in case people want to
bikeshed on the naming.

"code" has a nice property that it's exactly as many letters as
"base", so this patch didn't require any reindentation.  :-)

Change-Id: Id8dc06683a69fad80d88e674f65e826d6a4e3f66
2022-05-20 20:41:02 +01:00
Tom Tromey
a0cd5f080b Remove vtable_breakpoint_ops
There's no need to have vtable_breakpoint_ops any more, so remove it
in favor of base_breakpoint_ops.
2022-04-29 16:14:32 -06:00
Tom Tromey
7dd8e7ae28 Convert ordinary breakpoints to vtable ops
This converts "ordinary" breakpoint to use vtable_breakpoint_ops.
Recall that an ordinary breakpoint is both the kind normally created
by users, and also a base class used by other classes.
2022-04-29 16:14:31 -06:00
Tom Tromey
0d1703b8fb Remove "typedef enum ..."
I noticed a few spots in GDB that use "typedef enum".  However, in C++
this isn't as useful, as the tag is automatically entered as a
typedef.  This patch removes most uses of "typedef enum" -- the
exceptions being in some nat-* code I can't compile, and
glibc_thread_db.h, which I think is more or less a copy of some C code
from elsewhere.

Tested by rebuilding.
2022-04-28 09:31:15 -06:00
Simon Marchi
63d609debb gdb: remove BLOCKVECTOR_BLOCK and BLOCKVECTOR_NBLOCKS macros
Replace with calls to blockvector::blocks, and the appropriate method
call on the returned array_view.

Change-Id: I04d1f39603e4d4c21c96822421431d9a029d8ddd
2022-04-27 22:05:03 -04:00
Simon Marchi
f135fe728e gdb: remove BLOCK_SUPERBLOCK macro
Replace with equivalent methods.

Change-Id: I334a319909a50b5cc5570a45c38c70e10dc00630
2022-04-27 22:05:03 -04:00
Simon Marchi
6c00f721c8 gdb: remove BLOCK_FUNCTION macro
Replace with equivalent methods.

Change-Id: I31ec00f5bf85335c8b23d306ca0fe0b84d489101
2022-04-27 22:05:03 -04:00
Simon Marchi
4b8791e10e gdb: remove BLOCK_{START,END} macros
Replace with equivalent methods.

Change-Id: I10a6c8a2a86462d9d4a6a6409a3f07a6bea66310
2022-04-27 22:05:02 -04:00
Tom Tromey
4206d69e96 Replace symbol_symtab with symbol::symtab
This turns symbol_symtab into a method on symbol.  It also replaces
symbol_set_symtab with a method.
2022-04-20 09:28:40 -06:00
Tom Tromey
e19b2d9465 Replace symbol_objfile with symbol::objfile
This turns symbol_objfile into a method on symbol.
2022-04-20 09:28:16 -06:00
Simon Marchi
3c86fae3d9 gdb: remove symtab::objfile
Same idea as previous patch, but for symtab::objfile.  I find
it clearer without this wrapper, as it shows that the objfile is
common to all symtabs of a given compunit.  Otherwise, you could think
that each symtab (of a given compunit) can have a specific objfile.

Change-Id: Ifc0dbc7ec31a06eefa2787c921196949d5a6fcc6
2022-04-07 13:05:22 -04:00