* [PATCH] Use Python 2.[67] / 3.X / PEP 3118 buffer protocol
@ 2019-02-19 21:51 Kevin Buettner
2019-02-20 18:13 ` Tom Tromey
` (3 more replies)
0 siblings, 4 replies; 10+ messages in thread
From: Kevin Buettner @ 2019-02-19 21:51 UTC (permalink / raw)
To: gdb-patches
This patch removes the non-IS_PY3K code in infpy_write_memory()
and infpy_search_memory(). In both cases, the remaining code
from these ifdefs is related to use of the PEP 3118 buffer protocol.
(Deleted code is either due to simplification or related to use of the
old buffer protocol.) PEP 3118 is sometimes referred to as the "new"
buffer protocol, though it's not that new anymore.
The link below describes new features in Python 2.6. In particular,
it says that the buffer protocol described by PEP 3118 is in Python
2.6. It also says (at the top of the page) that Python 2.6 was
released on Oct 1, 2008.
https://docs.python.org/3/whatsnew/2.6.html#pep-3118-revised-buffer-protocol
The last security release for the Python 2.6 series was 2.6.9. It was
released on Oct 29, 2013. According to this document...
https://www.python.org/download/releases/2.6.9/
...support for the 2.6 series has ended:
With the 2.6.9 release, and five years after its first release,
the Python 2.6 series is now officially retired. All official
maintenance for Python 2.6, including security patches, has ended.
For ongoing maintenance releases, please see the Python 2.7
series.
As noted earlier, Python 2.6, Python 2.7, and Python 3.X all have
support for the PEP 3118 buffer protocol. Python releases prior
to 2.6 use an older buffer protocol. Since Python 2.6 has been
retired for a good while now, it seems reasonable to me to remove
code using the older buffer protocol from GDB.
I have also simplified some of the code via use of the Py_buffer
unique_ptr specialization which I introduced in the two argument
gdb.Value constructor patch series. Therefore, there is a dependency
on patch #1 from that series.
I have tested against both Python 2.7.15 and 3.7.2. I see no
regressions among the non-racy tests. I've also verified that
PyBuffer_Release is being called when the affected functions exit
while running the tests in gdb.python/py-inferior.exp by hand. I've
also tried running valgrind on GDB while running this test, but I'm
puzzled by the results that I'm seeing - I'm seeing no additional
leaks when I comment out the Py_buffer_up lines that I introduced.
That said, I'm not seeing any leaks that obviously originate from
either infpy_write_memory() or infpy_search_memory().
gdb/ChangeLog:
* python/py-inferior.c (infpy_write_memory): Remove non-IS_PY3K
code from these functions. Remove corresponding ifdefs. Use
Py_buffer_up instead of explicit calls to PyBuffer_Release.
Remove gotos and target of gotos.
(infpy_search_memory): Likewise.
---
gdb/python/py-inferior.c | 64 ++++++------------------------------------------
1 file changed, 8 insertions(+), 56 deletions(-)
diff --git a/gdb/python/py-inferior.c b/gdb/python/py-inferior.c
index 6fc6093f3a..eb6be23471 100644
--- a/gdb/python/py-inferior.c
+++ b/gdb/python/py-inferior.c
@@ -596,31 +596,23 @@ infpy_write_memory (PyObject *self, PyObject *args, PyObject *kw)
CORE_ADDR addr, length;
PyObject *addr_obj, *length_obj = NULL;
static const char *keywords[] = { "address", "buffer", "length", NULL };
-#ifdef IS_PY3K
Py_buffer pybuf;
if (!gdb_PyArg_ParseTupleAndKeywords (args, kw, "Os*|O", keywords,
&addr_obj, &pybuf, &length_obj))
return NULL;
+ Py_buffer_up buffer_up (&pybuf);
buffer = (const gdb_byte *) pybuf.buf;
buf_len = pybuf.len;
-#else
- if (!gdb_PyArg_ParseTupleAndKeywords (args, kw, "Os#|O", keywords,
- &addr_obj, &buffer, &buf_len,
- &length_obj))
- return NULL;
-
- buffer = (const gdb_byte *) buffer;
-#endif
if (get_addr_from_python (addr_obj, &addr) < 0)
- goto fail;
+ return nullptr;
if (!length_obj)
length = buf_len;
else if (get_addr_from_python (length_obj, &length) < 0)
- goto fail;
+ return nullptr;
TRY
{
@@ -632,18 +624,9 @@ infpy_write_memory (PyObject *self, PyObject *args, PyObject *kw)
}
END_CATCH
-#ifdef IS_PY3K
- PyBuffer_Release (&pybuf);
-#endif
GDB_PY_HANDLE_EXCEPTION (except);
Py_RETURN_NONE;
-
- fail:
-#ifdef IS_PY3K
- PyBuffer_Release (&pybuf);
-#endif
- return NULL;
}
/* Destructor of Membuf objects. */
@@ -752,7 +735,6 @@ infpy_search_memory (PyObject *self, PyObject *args, PyObject *kw)
const gdb_byte *buffer;
CORE_ADDR found_addr;
int found = 0;
-#ifdef IS_PY3K
Py_buffer pybuf;
if (!gdb_PyArg_ParseTupleAndKeywords (args, kw, "OOs*", keywords,
@@ -760,42 +742,21 @@ infpy_search_memory (PyObject *self, PyObject *args, PyObject *kw)
&pybuf))
return NULL;
+ Py_buffer_up buffer_up (&pybuf);
buffer = (const gdb_byte *) pybuf.buf;
pattern_size = pybuf.len;
-#else
- PyObject *pattern;
- const void *vbuffer;
-
- if (!gdb_PyArg_ParseTupleAndKeywords (args, kw, "OOO", keywords,
- &start_addr_obj, &length_obj,
- &pattern))
- return NULL;
-
- if (!PyObject_CheckReadBuffer (pattern))
- {
- PyErr_SetString (PyExc_RuntimeError,
- _("The pattern is not a Python buffer."));
-
- return NULL;
- }
-
- if (PyObject_AsReadBuffer (pattern, &vbuffer, &pattern_size) == -1)
- return NULL;
-
- buffer = (const gdb_byte *) vbuffer;
-#endif
if (get_addr_from_python (start_addr_obj, &start_addr) < 0)
- goto fail;
+ return nullptr;
if (get_addr_from_python (length_obj, &length) < 0)
- goto fail;
+ return nullptr;
if (!length)
{
PyErr_SetString (PyExc_ValueError,
_("Search range is empty."));
- goto fail;
+ return nullptr;
}
/* Watch for overflows. */
else if (length > CORE_ADDR_MAX
@@ -803,7 +764,7 @@ infpy_search_memory (PyObject *self, PyObject *args, PyObject *kw)
{
PyErr_SetString (PyExc_ValueError,
_("The search range is too large."));
- goto fail;
+ return nullptr;
}
TRY
@@ -818,21 +779,12 @@ infpy_search_memory (PyObject *self, PyObject *args, PyObject *kw)
}
END_CATCH
-#ifdef IS_PY3K
- PyBuffer_Release (&pybuf);
-#endif
GDB_PY_HANDLE_EXCEPTION (except);
if (found)
return PyLong_FromLong (found_addr);
else
Py_RETURN_NONE;
-
- fail:
-#ifdef IS_PY3K
- PyBuffer_Release (&pybuf);
-#endif
- return NULL;
}
/* Implementation of gdb.Inferior.is_valid (self) -> Boolean.
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH] Use Python 2.[67] / 3.X / PEP 3118 buffer protocol
2019-02-19 21:51 [PATCH] Use Python 2.[67] / 3.X / PEP 3118 buffer protocol Kevin Buettner
@ 2019-02-20 18:13 ` Tom Tromey
2019-02-26 17:47 ` Kevin Buettner
2019-02-20 19:05 ` Pedro Alves
` (2 subsequent siblings)
3 siblings, 1 reply; 10+ messages in thread
From: Tom Tromey @ 2019-02-20 18:13 UTC (permalink / raw)
To: Kevin Buettner; +Cc: gdb-patches
>>>>> "Kevin" == Kevin Buettner <kevinb@redhat.com> writes:
Kevin> This patch removes the non-IS_PY3K code in infpy_write_memory()
Kevin> and infpy_search_memory(). In both cases, the remaining code
Kevin> from these ifdefs is related to use of the PEP 3118 buffer protocol.
Kevin> (Deleted code is either due to simplification or related to use of the
Kevin> old buffer protocol.) PEP 3118 is sometimes referred to as the "new"
Kevin> buffer protocol, though it's not that new anymore.
Thanks for doing this.
Kevin> The link below describes new features in Python 2.6. In particular,
Kevin> it says that the buffer protocol described by PEP 3118 is in Python
Kevin> 2.6. It also says (at the top of the page) that Python 2.6 was
Kevin> released on Oct 1, 2008.
I think probably the NEWS file should be updated to mention the minimum
version bump. gdb.texinfo also currently says that Python 2.4 is the
minimum, so that should also be updated.
Kevin> I have tested against both Python 2.7.15 and 3.7.2. I see no
Kevin> regressions among the non-racy tests. I've also verified that
Kevin> PyBuffer_Release is being called when the affected functions exit
Kevin> while running the tests in gdb.python/py-inferior.exp by hand. I've
Kevin> also tried running valgrind on GDB while running this test, but I'm
Kevin> puzzled by the results that I'm seeing - I'm seeing no additional
Kevin> leaks when I comment out the Py_buffer_up lines that I introduced.
Maybe it's possible that PyBuffer_Release doesn't need to do anything in
particular in some scenarios? Like if the buffer it refers to is shared
with some other object? You'd have to dive into the Python
implementation to find out. Meanwhile if there is no leak introduced by
this code, then it seems fine to me.
The patch itself looks good to me.
Tom
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH] Use Python 2.[67] / 3.X / PEP 3118 buffer protocol
2019-02-20 18:13 ` Tom Tromey
@ 2019-02-26 17:47 ` Kevin Buettner
0 siblings, 0 replies; 10+ messages in thread
From: Kevin Buettner @ 2019-02-26 17:47 UTC (permalink / raw)
To: gdb-patches
On Wed, 20 Feb 2019 11:13:35 -0700
Tom Tromey <tom@tromey.com> wrote:
> Kevin> The link below describes new features in Python 2.6. In particular,
> Kevin> it says that the buffer protocol described by PEP 3118 is in Python
> Kevin> 2.6. It also says (at the top of the page) that Python 2.6 was
> Kevin> released on Oct 1, 2008.
>
> I think probably the NEWS file should be updated to mention the minimum
> version bump. gdb.texinfo also currently says that Python 2.4 is the
> minimum, so that should also be updated.
I've just posted a separate patch which does this.
Kevin
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] Use Python 2.[67] / 3.X / PEP 3118 buffer protocol
2019-02-19 21:51 [PATCH] Use Python 2.[67] / 3.X / PEP 3118 buffer protocol Kevin Buettner
2019-02-20 18:13 ` Tom Tromey
@ 2019-02-20 19:05 ` Pedro Alves
2019-02-20 20:49 ` Kevin Buettner
2019-02-26 17:45 ` Document fact that mininum Python version is now 2.6 Kevin Buettner
2019-02-27 18:17 ` [PATCH] Use Python 2.[67] / 3.X / PEP 3118 buffer protocol Kevin Buettner
3 siblings, 1 reply; 10+ messages in thread
From: Pedro Alves @ 2019-02-20 19:05 UTC (permalink / raw)
To: Kevin Buettner, gdb-patches
On 02/19/2019 09:51 PM, Kevin Buettner wrote:
> As noted earlier, Python 2.6, Python 2.7, and Python 3.X all have
> support for the PEP 3118 buffer protocol. Python releases prior
> to 2.6 use an older buffer protocol. Since Python 2.6 has been
> retired for a good while now, it seems reasonable to me to remove
> code using the older buffer protocol from GDB.
>
> I have also simplified some of the code via use of the Py_buffer
> unique_ptr specialization which I introduced in the two argument
> gdb.Value constructor patch series. Therefore, there is a dependency
> on patch #1 from that series.
Not objecting, but I think you should send an email to gdb@ with
a clear subject indicating that you're proposing to drop support
for Python < 2.6.
Thanks,
Pedro Alves
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] Use Python 2.[67] / 3.X / PEP 3118 buffer protocol
2019-02-20 19:05 ` Pedro Alves
@ 2019-02-20 20:49 ` Kevin Buettner
0 siblings, 0 replies; 10+ messages in thread
From: Kevin Buettner @ 2019-02-20 20:49 UTC (permalink / raw)
To: gdb-patches
On Wed, 20 Feb 2019 19:05:26 +0000
Pedro Alves <palves@redhat.com> wrote:
> On 02/19/2019 09:51 PM, Kevin Buettner wrote:
> > As noted earlier, Python 2.6, Python 2.7, and Python 3.X all have
> > support for the PEP 3118 buffer protocol. Python releases prior
> > to 2.6 use an older buffer protocol. Since Python 2.6 has been
> > retired for a good while now, it seems reasonable to me to remove
> > code using the older buffer protocol from GDB.
>
> Not objecting, but I think you should send an email to gdb@ with
> a clear subject indicating that you're proposing to drop support
> for Python < 2.6.
Okay, I've done this. See:
https://sourceware.org/ml/gdb/2019-02/msg00020.html
Kevin
^ permalink raw reply [flat|nested] 10+ messages in thread
* Document fact that mininum Python version is now 2.6
2019-02-19 21:51 [PATCH] Use Python 2.[67] / 3.X / PEP 3118 buffer protocol Kevin Buettner
2019-02-20 18:13 ` Tom Tromey
2019-02-20 19:05 ` Pedro Alves
@ 2019-02-26 17:45 ` Kevin Buettner
2019-02-26 18:29 ` Eli Zaretskii
2019-02-27 18:17 ` [PATCH] Use Python 2.[67] / 3.X / PEP 3118 buffer protocol Kevin Buettner
3 siblings, 1 reply; 10+ messages in thread
From: Kevin Buettner @ 2019-02-26 17:45 UTC (permalink / raw)
To: gdb-patches; +Cc: Eli Zaretskii
gdb/ChangeLog:
* NEWS: Note minimum Python version.
gdb/doc/ChangeLog:
* gdb.texinfo (Configure Options): Document minimum python
version.
diff --git a/gdb/NEWS b/gdb/NEWS
index bfb023e7bb..e2f1907db4 100644
--- a/gdb/NEWS
+++ b/gdb/NEWS
@@ -188,6 +188,8 @@ FreeBSD/riscv riscv*-*-freebsd*
* Python API
+ ** GDB no longer supports Python versions less than 2.6.
+
** The gdb.Inferior type has a new 'progspace' property, which is the program
space associated to that inferior.
diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index 7b2e5578bd..8b61cc1ba3 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -35975,7 +35975,7 @@ libpython is present and found at configure time.) Python makes
@value{GDBN} scripting much more powerful than the restricted CLI
scripting language. If your host does not have Python installed, you
can find it on `http://www.python.org/download/'. The oldest version
-of Python supported by GDB is 2.4. The optional argument @var{python}
+of Python supported by GDB is 2.6. The optional argument @var{python}
is used to find the Python headers and libraries. It can be either
the name of a Python executable, or the name of the directory in which
Python is installed.
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: Document fact that mininum Python version is now 2.6
2019-02-26 17:45 ` Document fact that mininum Python version is now 2.6 Kevin Buettner
@ 2019-02-26 18:29 ` Eli Zaretskii
2019-02-27 18:18 ` Kevin Buettner
0 siblings, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2019-02-26 18:29 UTC (permalink / raw)
To: Kevin Buettner; +Cc: gdb-patches
> Date: Tue, 26 Feb 2019 10:45:33 -0700
> From: Kevin Buettner <kevinb@redhat.com>
> Cc: Eli Zaretskii <eliz@gnu.org>
>
> gdb/ChangeLog:
>
> * NEWS: Note minimum Python version.
>
> gdb/doc/ChangeLog:
>
> * gdb.texinfo (Configure Options): Document minimum python
> version.
Thanks, this is OK.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Document fact that mininum Python version is now 2.6
2019-02-26 18:29 ` Eli Zaretskii
@ 2019-02-27 18:18 ` Kevin Buettner
2019-02-27 19:01 ` Kevin Buettner
0 siblings, 1 reply; 10+ messages in thread
From: Kevin Buettner @ 2019-02-27 18:18 UTC (permalink / raw)
To: gdb-patches
On Tue, 26 Feb 2019 20:29:07 +0200
Eli Zaretskii <eliz@gnu.org> wrote:
> > Date: Tue, 26 Feb 2019 10:45:33 -0700
> > From: Kevin Buettner <kevinb@redhat.com>
> > Cc: Eli Zaretskii <eliz@gnu.org>
> >
> > gdb/ChangeLog:
> >
> > * NEWS: Note minimum Python version.
> >
> > gdb/doc/ChangeLog:
> >
> > * gdb.texinfo (Configure Options): Document minimum python
> > version.
>
> Thanks, this is OK.
Thanks for the review.
I've pushed this change.
Kevin
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Document fact that mininum Python version is now 2.6
2019-02-27 18:18 ` Kevin Buettner
@ 2019-02-27 19:01 ` Kevin Buettner
0 siblings, 0 replies; 10+ messages in thread
From: Kevin Buettner @ 2019-02-27 19:01 UTC (permalink / raw)
To: gdb-patches
On Wed, 27 Feb 2019 11:18:09 -0700
Kevin Buettner <kevinb@redhat.com> wrote:
> > > gdb/ChangeLog:
> > >
> > > * NEWS: Note minimum Python version.
> > >
> > > gdb/doc/ChangeLog:
> > >
> > > * gdb.texinfo (Configure Options): Document minimum python
> > > version.
> >
> > Thanks, this is OK.
>
> Thanks for the review.
>
> I've pushed this change.
I realized that, in conjunction with Joel's changes to the NEWS file,
this push now says that gdb-8.3 no longer supports Python versions
less than 2.6. This is technically true due to the commit of the
two argument version of gdb.Value that I pushed yesterday.
(That commit uses the PEP 3118 buffer protocol which is only
supported in Python versions 2.6 and up.)
So...
I've pushed this documentation commit to gdb-8.3-branch also.
I won't push "Use Python 2.[67] / 3.X / PEP 3118 buffer protocol"
to the gdb-8.3-branch unless someone asks for it though.
Kevin
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] Use Python 2.[67] / 3.X / PEP 3118 buffer protocol
2019-02-19 21:51 [PATCH] Use Python 2.[67] / 3.X / PEP 3118 buffer protocol Kevin Buettner
` (2 preceding siblings ...)
2019-02-26 17:45 ` Document fact that mininum Python version is now 2.6 Kevin Buettner
@ 2019-02-27 18:17 ` Kevin Buettner
3 siblings, 0 replies; 10+ messages in thread
From: Kevin Buettner @ 2019-02-27 18:17 UTC (permalink / raw)
To: gdb-patches
On Tue, 19 Feb 2019 14:51:10 -0700
Kevin Buettner <kevinb@redhat.com> wrote:
> gdb/ChangeLog:
>
> * python/py-inferior.c (infpy_write_memory): Remove non-IS_PY3K
> code from these functions. Remove corresponding ifdefs. Use
> Py_buffer_up instead of explicit calls to PyBuffer_Release.
> Remove gotos and target of gotos.
> (infpy_search_memory): Likewise.
Pushed.
Kevin
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2019-02-27 19:01 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-02-19 21:51 [PATCH] Use Python 2.[67] / 3.X / PEP 3118 buffer protocol Kevin Buettner
2019-02-20 18:13 ` Tom Tromey
2019-02-26 17:47 ` Kevin Buettner
2019-02-20 19:05 ` Pedro Alves
2019-02-20 20:49 ` Kevin Buettner
2019-02-26 17:45 ` Document fact that mininum Python version is now 2.6 Kevin Buettner
2019-02-26 18:29 ` Eli Zaretskii
2019-02-27 18:18 ` Kevin Buettner
2019-02-27 19:01 ` Kevin Buettner
2019-02-27 18:17 ` [PATCH] Use Python 2.[67] / 3.X / PEP 3118 buffer protocol Kevin Buettner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox