diff options
author | Andrew Burgess <andrew.burgess@embecosm.com> | 2021-09-01 14:24:15 +0100 |
---|---|---|
committer | Andrew Burgess <andrew.burgess@embecosm.com> | 2021-09-09 09:50:38 +0100 |
commit | 0b233e34c801eac78a5e03b66f18585cf368e4d5 (patch) | |
tree | ffbf9145c61b0c3bb07b08b206f703fc9cc92a82 /gdb/python/py-block.c | |
parent | 21b9b99cd797fd2581ed559b89ec0c2cc6e87edf (diff) | |
download | gdb-0b233e34c801eac78a5e03b66f18585cf368e4d5.zip gdb-0b233e34c801eac78a5e03b66f18585cf368e4d5.tar.gz gdb-0b233e34c801eac78a5e03b66f18585cf368e4d5.tar.bz2 |
gdb/python: remove all uses of Py_TPFLAGS_HAVE_ITER
Python 2 has a bit flag Py_TPFLAGS_HAVE_ITER which can be passed as
part of the tp_flags field when defining a new object type. This flag
is not defined in Python 3 and so we define it to 0 in
python-internal.h (when IS_PY3K is defined).
The meaning of this flag is that the object has the fields tp_iter and
tp_iternext. Note the use of "has" here, the flag says nothing about
the values in those fields, just that the type object has the fields.
In early versions of Python 2 these fields were no part of the
PyTypeObject struct, they were added in version 2.2 (see
https://docs.python.org/release/2.3/api/type-structs.html). And so,
there could be a some code compiled out there which has a PyTypeObject
structure within it that doesn't even have the tp_iter and tp_iternext
fields, attempting to access these fields would be undefined
behaviour.
And so Python added the Py_TPFLAGS_HAVE_ITER flag. If the flag is
present then Python is free to access the tp_iter and tp_iternext
fields.
If we consider GDB then we always assume that the tp_iter and
tp_iternext fields are part of PyTypeObject. If someone was crazy
enough to try and compile GDB against Python 2.1 then we'd get lots of
build errors saying that we were passing too many fields when
initializing PyTypeObject structures. And so, I claim, we can be sure
that GDB will always be compiled with a version of Python that has the
tp_iter and tp_iternext fields in PyTypeObject.
Next we can look at the Py_TPFLAGS_DEFAULT flag. In Python 2, each
time additional fields are added to PyTypeObject a new Py_TPFLAGS_*
flag would be defined to indicate whether those flags are present or
not. And, those new flags would be added to Py_TPFLAGS_DEFAULT. And
so, in the latest version of Python 2 the Py_TPFLAGS_DEFAULT flag
includes Py_TPFLAGS_HAVE_ITER (see
https://docs.python.org/2.7/c-api/typeobj.html).
In GDB we pass Py_TPFLAGS_DEFAULT as part of the tp_flags for all
objects we define.
And so, in this commit, I propose to remove all uses of
Py_TPFLAGS_HAVE_ITER from GDB, it's simply not needed.
There should be no user visible changes after this commit.
Diffstat (limited to 'gdb/python/py-block.c')
-rw-r--r-- | gdb/python/py-block.c | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/gdb/python/py-block.c b/gdb/python/py-block.c index 244ff9a..fe0efd6 100644 --- a/gdb/python/py-block.c +++ b/gdb/python/py-block.c @@ -510,7 +510,7 @@ PyTypeObject block_object_type = { 0, /*tp_getattro*/ 0, /*tp_setattro*/ 0, /*tp_as_buffer*/ - Py_TPFLAGS_DEFAULT | Py_TPFLAGS_HAVE_ITER, /*tp_flags*/ + Py_TPFLAGS_DEFAULT, /*tp_flags*/ "GDB block object", /* tp_doc */ 0, /* tp_traverse */ 0, /* tp_clear */ @@ -550,7 +550,7 @@ PyTypeObject block_syms_iterator_object_type = { 0, /*tp_getattro*/ 0, /*tp_setattro*/ 0, /*tp_as_buffer*/ - Py_TPFLAGS_DEFAULT | Py_TPFLAGS_HAVE_ITER, /*tp_flags*/ + Py_TPFLAGS_DEFAULT, /*tp_flags*/ "GDB block syms iterator object", /*tp_doc */ 0, /*tp_traverse */ 0, /*tp_clear */ |