diff options
author | Andrew Burgess <aburgess@redhat.com> | 2024-01-04 14:24:12 +0000 |
---|---|---|
committer | Andrew Burgess <aburgess@redhat.com> | 2024-01-12 11:21:28 +0000 |
commit | 2f47f48fe55eb72bfe4d3c5291a74f4a53121c5e (patch) | |
tree | c5120bbce76f071a5dfd82b6e2d1780d85a4adcf /cpu | |
parent | d6defe8761ca7db47e3c1e1168f7869ffbb7e087 (diff) | |
download | gdb-2f47f48fe55eb72bfe4d3c5291a74f4a53121c5e.zip gdb-2f47f48fe55eb72bfe4d3c5291a74f4a53121c5e.tar.gz gdb-2f47f48fe55eb72bfe4d3c5291a74f4a53121c5e.tar.bz2 |
gdb/python: remove users ability to create gdb.Progspace objects
I noticed that it is possible for the user to create a new
gdb.Progspace object, like this:
(gdb) pi
>>> p = gdb.Progspace()
>>> p
<gdb.Progspace object at 0x7ffad4219c10>
>>> p.is_valid()
False
As the new gdb.Progspace object is not associated with an actual C++
program_space object within GDB core, then the new gdb.Progspace is
created invalid, and there is no way in which the new object can ever
become valid.
Nor do I believe there's anywhere in the Python API where it makes
sense to consume an invalid gdb.Progspace created in this way, for
example, the gdb.Progspace could be passed as the locus to
register_type_printer, but all that would happen is that the
registered printer would never be used.
In this commit I propose to remove the ability to create new
gdb.Progspace objects. Attempting to do so now gives an error, like
this:
(gdb) pi
>>> gdb.Progspace()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: cannot create 'gdb.Progspace' instances
Of course, there is a small risk here that some existing user code
might break ... but if that happens I don't believe the user code can
have been doing anything useful, so I see this as a small risk.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
Diffstat (limited to 'cpu')
0 files changed, 0 insertions, 0 deletions