From: Tom Tromey <tom@tromey.com>
To: Kevin Buettner <kevinb@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] Use Python 2.[67] / 3.X / PEP 3118 buffer protocol
Date: Wed, 20 Feb 2019 18:13:00 -0000 [thread overview]
Message-ID: <87ftsipbu8.fsf@tromey.com> (raw)
In-Reply-To: <20190219145110.03bccce6@f29-4.lan> (Kevin Buettner's message of "Tue, 19 Feb 2019 14:51:10 -0700")
>>>>> "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
next prev parent reply other threads:[~2019-02-20 18:13 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-19 21:51 Kevin Buettner
2019-02-20 18:13 ` Tom Tromey [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ftsipbu8.fsf@tromey.com \
--to=tom@tromey.com \
--cc=gdb-patches@sourceware.org \
--cc=kevinb@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox