aboutsummaryrefslogtreecommitdiff
path: root/gdb/python/py-block.c
diff options
context:
space:
mode:
authorAndrew Burgess <andrew.burgess@embecosm.com>2021-09-01 14:24:15 +0100
committerAndrew Burgess <andrew.burgess@embecosm.com>2021-09-09 09:50:38 +0100
commit0b233e34c801eac78a5e03b66f18585cf368e4d5 (patch)
treeffbf9145c61b0c3bb07b08b206f703fc9cc92a82 /gdb/python/py-block.c
parent21b9b99cd797fd2581ed559b89ec0c2cc6e87edf (diff)
downloadgdb-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.c4
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 */