From: "Wiederhake, Tim" <tim.wiederhake@intel.com>
To: Yao Qi <qiyaoltc@gmail.com>,
"Jose E. Marchesi" <jose.marchesi@oracle.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: RE: MemoryView missing from Python 2.4 and 2.6
Date: Fri, 24 Feb 2017 10:37:00 -0000 [thread overview]
Message-ID: <9676A094AF46E14E8265E7A3F4CCE9AF9417D1@irsmsx105.ger.corp.intel.com> (raw)
In-Reply-To: <20170223225946.snir4ab6twc7vo7n@localhost>
Hi all!
It seems like indeed my code is incompatible with Python 2.4, which according to
the README file is still supported by GDB.
My understanding (correct me if I'm wrong) is that in Python there is the
"old style buffer API", the "new style buffer api" and "memory views".
From: https://docs.python.org/2.7/c-api/buffer.html:
- "old style buffer API": Deprecated in 2.7, removed in 3.0
- "new style buffer API": Introduced in 3.0, backported to 2.6
- "memory view": Introduced in 3.0, backported to 2.7 (used bypy_record_btrace)
That means that there is no buffer API that covers the complete range of Python
versions that are supported by GDB (2.4 to 3.x).
This leaves us with four possible courses of action:
1) Drop the support for Python 2.4, 2.5, 2.6, 3.0, 3.1 and 3.2, making GDB
support "Versions 2.7 and >= 3.3". Rationale:
According to https://docs.python.org/devguide/index.html#branchstatus these
versions are end-of-life'd and do not receive any security patches anymore:
Version Released End-of-life
3.2 2011-02-20 2016-02-20
3.1 2009-06-27 2012-04-11
3.0 2008-12-03 2009-01-13
2.6 2008-10-01 2013-10-29
(Versions < 2.6 are not even listed any more on that page.)
This would fix the situation immediately but annoy Jose.
2) Refactor "gdb.Membuf" from python/py-inferior.c into its own file and use
that. I don't like this idea too much because it is basically reinventing the
wheel and gdb.Membuf is less versatile than build-in buffers, strings, etc.
3) Use the "new style buffer API" and limit GDB's support to Python >= 2.6.
In this case we would have to limit the supported Python versions anyway so
on the one hand there is not much reason to not throw out 2.6 as well. On the
other hand, there still seem to be some Python 2.6 users.
4) Return a string in "gdb.BtraceInstruction.data ()". The instruction data can
potentially contain null bytes which can cause issues for obvious reasons.
Regards,
Tim
> -----Original Message-----
> From: gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] On Behalf Of Yao Qi
> Sent: Friday, February 24, 2017 12:00 AM
> To: Jose E. Marchesi <jose.marchesi@oracle.com>; Wiederhake, Tim
> <tim.wiederhake@intel.com>
> Cc: gdb-patches@sourceware.org; Metzger, Markus T
> <markus.t.metzger@intel.com>
> Subject: Re: MemoryView missing from Python 2.4 and 2.6
>
> On 17-02-23 17:48:20, Jose E. Marchesi wrote:
> > While building git GDB on a certain distribution that features Python
> > 2.6.6 (I know, ancient) we triggered a build failure:
> >
> > g++ -g -O2 -I. -I../../gdb -I../../gdb/common -I../../gdb/config -
> DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H -
> I../../gdb/../include/opcode -I../../gdb/../opcodes/.. -I../../gdb/../readline/..
> -I../../gdb/../zlib -I../bfd -I../../gdb/../bfd -I../../gdb/../include -
> I../libdecnumber -I../../gdb/../libdecnumber -I../../gdb/gnulib/import -
> Ibuild-gnulib/import -DTUI=1 -I/usr/include/python2.6 -
> I/usr/include/python2.6 -Wall -Wpointer-arith -Wno-unused -Wunused-
> value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body
> -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-
> compare -Wno-write-strings -Wno-narrowing -Wformat-nonliteral -Werror -c
> -o py-record-btrace.o -MT py-record-btrace.o -MMD -MP -MF .deps/py-
> record-btrace.Tpo -fno-strict-aliasing -DNDEBUG -fwrapv
> ../../gdb/python/py-record-btrace.c
> > ../../gdb/python/py-record-btrace.c: In function ???PyObject*
> btpy_insn_data(PyObject*, void*)???:
> > ../../gdb/python/py-record-btrace.c:333:10: error:
> ???PyMemoryView_FromObject??? was not declared in this scope
> > return PyMemoryView_FromObject (object);
> > ^~~~~~~~~~~~~~~~~~~~~~~
> > ../../gdb/python/py-record-btrace.c:333:10: note: suggested alternative:
> ???PyBuffer_FromObject???
> > return PyMemoryView_FromObject (object);
> > ^~~~~~~~~~~~~~~~~~~~~~~
> > PyBuffer_FromObject
> > make: *** [py-record-btrace.o] Error 1
> >
> > Looks like the Memory View object was introduced in Python 2.7.
>
> Hi Tim,
> Could you take a look?
>
> --
> Yao
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
next prev parent reply other threads:[~2017-02-24 10:37 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-23 16:48 Jose E. Marchesi
2017-02-23 17:06 ` Jose E. Marchesi
2017-02-23 22:59 ` Yao Qi
2017-02-24 10:37 ` Wiederhake, Tim [this message]
2017-02-24 16:06 ` Yao Qi
2017-02-24 16:14 ` Paul.Koning
2017-02-28 10:53 ` Wiederhake, Tim
2017-02-28 12:51 ` Jose E. Marchesi
2017-03-07 0:21 ` Joel Brobecker
2017-03-07 13:38 ` Wiederhake, Tim
2017-03-07 15:27 ` Joel Brobecker
2017-03-03 10:21 ` Yao Qi
2017-03-06 8:56 ` Wiederhake, Tim
2017-03-07 10:32 ` Yao Qi
2017-03-07 17:18 ` Wiederhake, Tim
2017-03-17 15:59 ` Yao Qi
2017-03-17 16:39 ` Jose E. Marchesi
2017-03-20 9:04 ` Yao Qi
2017-03-20 22:44 ` Yao Qi
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=9676A094AF46E14E8265E7A3F4CCE9AF9417D1@irsmsx105.ger.corp.intel.com \
--to=tim.wiederhake@intel.com \
--cc=gdb-patches@sourceware.org \
--cc=jose.marchesi@oracle.com \
--cc=qiyaoltc@gmail.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