MemoryView missing from Python 2.4 and 2.6

MemoryView missing from Python 2.4 and 2.6

[Jose E. Marchesi]

Hi folks!

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.
Salud!

Re: MemoryView missing from Python 2.4 and 2.6

[Jose E. Marchesi]

    While building git GDB on a certain distribution that features Python
    2.6.6 (I know, ancient) we triggered a build failure:

I just filed BZ 21196 for this.

Re: MemoryView missing from Python 2.4 and 2.6

[Yao Qi]

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 

RE: MemoryView missing from Python 2.4 and 2.6

[Wiederhake, Tim]

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

Re: MemoryView missing from Python 2.4 and 2.6

[Yao Qi]

"Wiederhake, Tim" <tim.wiederhake@intel.com> writes:

Hi Tim,

> 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.

Before we think of them carefully, could you tell us how is the python
api "gdb.BtraceInstruction.data ()" affected by these options?  From a
GDB python api user's point of view, they use gdb.BtraceInstruction.data()
in their python code, if we take one of these options, and change it, do
they need to change their code too?  Once "gdb.BtraceInstruction.data()"
is released, it is harder to change it in the later releases.
Secondly, GDB can't be built with python 2.6 and 2.4, we still need to
think about whether python 2.4 and 2.6 is supported or not in GDB 8.0
release.

-- 
Yao (齐尧)

Re: MemoryView missing from Python 2.4 and 2.6

[Paul.Koning]

"Wiederhake, Tim" <tim.wiederhake@intel.com> writes:

> ...
> 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.


That makes sense.

> 4) Return a string in "gdb.BtraceInstruction.data ()". The instruction data can
> potentially contain null bytes which can cause issues for obvious reasons.

Python has no problem at all with null bytes in strings.  

	paul

RE: MemoryView missing from Python 2.4 and 2.6

[Wiederhake, Tim]

[-- Attachment #1: Type: text/plain, Size: 1027 bytes --]

Hi,

thank you for your patience.
I revisited option (2) and found that I could actually do without big code refactoring. See attached patch how this could look like. "memoryview" offers some functions and data members that "buffer" does not have, like information about the stride size, the number of dimensions and explicit conversion functions to "bytes" and "list". Since we always return a one-dimensional array of bytes, this information is not too useful and is probably bearable to miss in Python 2. Besides these differences, the behavior is the same in regard to indexing and iterating over the object.

Jose, can you confirm that this patch un-breaks GDB linked with Python 2.6?

Regards,
Tim
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

[-- Attachment #2: 0001-Fix-break-on-Python-2.patch --]
[-- Type: application/octet-stream, Size: 1707 bytes --]

From 1e3c5400b84af756f6bc596b626d773be7bebdeb Mon Sep 17 00:00:00 2001
From: Tim Wiederhake <tim.wiederhake@intel.com>
Date: Tue, 28 Feb 2017 09:10:58 +0100
Subject: [PATCH] Fix break on Python 2

This changes the return type of "gdb.BtraceInstruction.data ()" from
"memoryview" to "buffer" on Python 2.7 and below, similar to what
"gdb.Inferior.read_memory ()" does.

gdb/ChangeLog:

	* python/py-record-btrace.c (btpy_insn_data): Change return type
	for Python 2.

gdb/doc/ChangeLog:

	* python.texi (Recordings In Python): Document return type of
	gdb.BtraceInstruction.data.

---
 gdb/doc/python.texi           | 3 ++-
 gdb/python/py-record-btrace.c | 5 +++++
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/gdb/doc/python.texi b/gdb/doc/python.texi
index c3ea203..b4a52bd 100644
--- a/gdb/doc/python.texi
+++ b/gdb/doc/python.texi
@@ -3181,7 +3181,8 @@ if the instruction is a gap or the debug symbols could not be read.
 
 @defvar BtraceInstruction.data
 A buffer with the raw instruction data.  May be @code{None} if the
-instruction is a gap.
+instruction is a gap.  In Python 3, the return value is a @code{memoryview}
+object.
 @end defvar
 
 @defvar BtraceInstruction.decoded
diff --git a/gdb/python/py-record-btrace.c b/gdb/python/py-record-btrace.c
index 6158f31..c816332 100644
--- a/gdb/python/py-record-btrace.c
+++ b/gdb/python/py-record-btrace.c
@@ -330,7 +330,12 @@ btpy_insn_data (PyObject *self, void *closure)
   if (object == NULL)
     return NULL;
 
+#ifdef IS_PY3K
   return PyMemoryView_FromObject (object);
+#else
+  return PyBuffer_FromObject (object, 0, Py_END_OF_BUFFER);
+#endif
+
 }
 
 /* Implementation of BtraceInstruction.decode [str].  Returns
-- 
2.7.4

Re: MemoryView missing from Python 2.4 and 2.6

[Jose E. Marchesi]

    Jose, can you confirm that this patch un-breaks GDB linked with
    Python 2.6?

Yep.  This fixes the build with Python 2.6.6.

Re: MemoryView missing from Python 2.4 and 2.6

[Yao Qi]

"Wiederhake, Tim" <tim.wiederhake@intel.com> writes:

> This changes the return type of "gdb.BtraceInstruction.data ()" from
> "memoryview" to "buffer" on Python 2.7 and below, similar to what
> "gdb.Inferior.read_memory ()" does.

The change looks reasonable to me.  Do we need to update test case?
In py-inferior.exp, we have

gdb_py_test_silent_cmd "python str = gdb.inferiors()\[0\].read_memory (addr, 5); print(str)" \
  "read str contents" 1
if { $gdb_py_is_py3k == 0 } {
  gdb_py_test_silent_cmd "python a = 'a'" "" 0
} else {
  gdb_py_test_silent_cmd "python a = bytes('a', 'ascii')" "" 0
}

I assume we need something similar here.

-- 
Yao (齐尧)

RE: MemoryView missing from Python 2.4 and 2.6

[Wiederhake, Tim]

[-- Attachment #1: Type: text/plain, Size: 1607 bytes --]

Hi Yao,

> The change looks reasonable to me.  Do we need to update test case?
> In py-inferior.exp, we have (...)

Thanks for the pointer. I've attached a revised version of the patch.

Tim

> -----Original Message-----
> From: gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] On Behalf Of Yao Qi
> Sent: Friday, March 3, 2017 11:22 AM
> To: Wiederhake, Tim <tim.wiederhake@intel.com>
> Cc: Jose E. Marchesi <jose.marchesi@oracle.com>; gdb-
> patches@sourceware.org
> Subject: Re: MemoryView missing from Python 2.4 and 2.6
> 
> "Wiederhake, Tim" <tim.wiederhake@intel.com> writes:
> 
> > This changes the return type of "gdb.BtraceInstruction.data ()" from
> > "memoryview" to "buffer" on Python 2.7 and below, similar to what
> > "gdb.Inferior.read_memory ()" does.
> 
> The change looks reasonable to me.  Do we need to update test case?
> In py-inferior.exp, we have
> 
> gdb_py_test_silent_cmd "python str = gdb.inferiors()\[0\].read_memory
> (addr, 5); print(str)" \
>   "read str contents" 1
> if { $gdb_py_is_py3k == 0 } {
>   gdb_py_test_silent_cmd "python a = 'a'" "" 0 } else {
>   gdb_py_test_silent_cmd "python a = bytes('a', 'ascii')" "" 0 }
> 
> I assume we need something similar here.
> 
> --
> 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

[-- Attachment #2: v2-0001-Fix-break-on-Python-2.patch --]
[-- Type: application/octet-stream, Size: 2818 bytes --]

From 093c751500597f503b5cc24955765fc746a86f33 Mon Sep 17 00:00:00 2001
From: Tim Wiederhake <tim.wiederhake@intel.com>
Date: Tue, 28 Feb 2017 09:10:58 +0100
Subject: [PATCH v2] Fix break on Python 2

This changes the return type of "gdb.BtraceInstruction.data ()" from
"memoryview" to "buffer" on Python 2.7 and below, similar to what
"gdb.Inferior.read_memory ()" does.

2017-03-06  Tim Wiederhake  <tim.wiederhake@intel.com>

gdb/ChangeLog:

	* python/py-record-btrace.c (btpy_insn_data): Change return type
	for Python 2.

gdb/doc/ChangeLog:

	* python.texi (Recordings In Python): Document return type of
	gdb.BtraceInstruction.data.

gdb/testsuite/ChangeLog:
	* gdb.python/py-record-btrace.exp: Check for buffer on Python 2
	and memory view on Python 3.


---
 gdb/doc/python.texi                           | 3 ++-
 gdb/python/py-record-btrace.c                 | 5 +++++
 gdb/testsuite/gdb.python/py-record-btrace.exp | 6 +++++-
 3 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/gdb/doc/python.texi b/gdb/doc/python.texi
index c3ea203..b4a52bd 100644
--- a/gdb/doc/python.texi
+++ b/gdb/doc/python.texi
@@ -3181,7 +3181,8 @@ if the instruction is a gap or the debug symbols could not be read.
 
 @defvar BtraceInstruction.data
 A buffer with the raw instruction data.  May be @code{None} if the
-instruction is a gap.
+instruction is a gap.  In Python 3, the return value is a @code{memoryview}
+object.
 @end defvar
 
 @defvar BtraceInstruction.decoded
diff --git a/gdb/python/py-record-btrace.c b/gdb/python/py-record-btrace.c
index 6158f31..c816332 100644
--- a/gdb/python/py-record-btrace.c
+++ b/gdb/python/py-record-btrace.c
@@ -330,7 +330,12 @@ btpy_insn_data (PyObject *self, void *closure)
   if (object == NULL)
     return NULL;
 
+#ifdef IS_PY3K
   return PyMemoryView_FromObject (object);
+#else
+  return PyBuffer_FromObject (object, 0, Py_END_OF_BUFFER);
+#endif
+
 }
 
 /* Implementation of BtraceInstruction.decode [str].  Returns
diff --git a/gdb/testsuite/gdb.python/py-record-btrace.exp b/gdb/testsuite/gdb.python/py-record-btrace.exp
index 65a3e7d..7752cac 100644
--- a/gdb/testsuite/gdb.python/py-record-btrace.exp
+++ b/gdb/testsuite/gdb.python/py-record-btrace.exp
@@ -85,7 +85,11 @@ with_test_prefix "instruction " {
     gdb_test "python print(i.error)" "None"
     gdb_test "python print(i.sal)" "symbol and line for .*"
     gdb_test "python print(i.pc)" "$decimal"
-    gdb_test "python print(i.data)" "<memory at $hex>"
+    if { $gdb_py_is_py3k == 0 } {
+	gdb_test "python print(repr(i.data))" "<read-only buffer for $hex,.*>"
+    } else {
+	gdb_test "python print(repr(i.data))" "<memory at $hex>"
+    }
     gdb_test "python print(i.decoded)" ".*"
     gdb_test "python print(i.size)" "$decimal"
     gdb_test "python print(i.is_speculative)" "False"
-- 
2.7.4

Re: MemoryView missing from Python 2.4 and 2.6

[Joel Brobecker]

Hello,

>     Jose, can you confirm that this patch un-breaks GDB linked with
>     Python 2.6?
> 
> Yep.  This fixes the build with Python 2.6.6.

It looks like the patch is also removing the feature from users
of Python 2.7.x, though, is it not? Given that this is a new feature,
this wouldn't be the end of the world, especially since we're so
close to branching, so we wouldn't want that to be a reason to
delay the fix too much longer. However, I think our configure
script defines HAVE_LIBPYTHON2_7, so perhaps we could either
use that, or explicitly exclude HAVE_LIBPYTHON2_6, HAVE_LIBPYTHON2_5
and HAVE_LIBPYTHON2_4 instead of only including it for Python 3.x?

-- 
Joel

Re: MemoryView missing from Python 2.4 and 2.6

[Yao Qi]

"Wiederhake, Tim" <tim.wiederhake@intel.com> writes:

> Thanks for the pointer. I've attached a revised version of the patch.

Hi Tim,
Did you run py-record-btrace.xp with python 2.6? or probably Jose
can help to run it with python 2.6.

If the test Tim added pass with both python 2.6 and python 3, your patch
is OK.

-- 
Yao (齐尧)

RE: MemoryView missing from Python 2.4 and 2.6

[Wiederhake, Tim]

Hi Joel!

> It looks like the patch is also removing the feature from users of
> Python 2.7.x, though, is it not?

The patch (see https://sourceware.org/ml/gdb-patches/2017-03/msg00039.html)
does not remove any feature.  The patch changes the return type of one function
from "memoryview" to "buffer" for Python 2.7 and below.  Both types support the
"in" keyword, indexed access, length etc. and behave very similar.  Granted,
memoryview has some additional functions that lets the user inspect the stride
and size of the elements in the buffer, but this is a feature we do not use
here anyway.

I chose 2.7 as a parting point because that is how it is  handled in
infpy_read_memory in py-inferior.c.  Personally, I would leave it that way
because with "buffer" exposed with Python 2.7 as well as Python 2.6 and below,
I guess it gets more exposure and testing and won't suffer bit-rot as easily.

The patch is tested with Python 2.7 and Python 3.6.  I cannot test it with
Python 2.6 but that should not be necessary as these two versions already check
both different return types.

Tim

> -----Original Message-----
> From: Joel Brobecker [mailto:brobecker@adacore.com]
> Sent: Tuesday, March 7, 2017 1:21 AM
> To: Jose E. Marchesi <jose.marchesi@oracle.com>
> Cc: Wiederhake, Tim <tim.wiederhake@intel.com>; Yao Qi
> <qiyaoltc@gmail.com>; gdb-patches@sourceware.org
> Subject: Re: MemoryView missing from Python 2.4 and 2.6
> 
> Hello,
> 
> >     Jose, can you confirm that this patch un-breaks GDB linked with
> >     Python 2.6?
> >
> > Yep.  This fixes the build with Python 2.6.6.
> 
> It looks like the patch is also removing the feature from users of Python 2.7.x,
> though, is it not? Given that this is a new feature, this wouldn't be the end of
> the world, especially since we're so close to branching, so we wouldn't want
> that to be a reason to delay the fix too much longer. However, I think our
> configure script defines HAVE_LIBPYTHON2_7, so perhaps we could either
> use that, or explicitly exclude HAVE_LIBPYTHON2_6, HAVE_LIBPYTHON2_5
> and HAVE_LIBPYTHON2_4 instead of only including it for Python 3.x?
> 
> --
> Joel
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

Re: MemoryView missing from Python 2.4 and 2.6

[Joel Brobecker]

> > It looks like the patch is also removing the feature from users of
> > Python 2.7.x, though, is it not?
> 
> The patch (see
> https://sourceware.org/ml/gdb-patches/2017-03/msg00039.html) does not
> remove any feature.  The patch changes the return type of one function
> from "memoryview" to "buffer" for Python 2.7 and below.  Both types
> support the "in" keyword, indexed access, length etc. and behave very
> similar.  Granted, memoryview has some additional functions that lets
> the user inspect the stride and size of the elements in the buffer,
> but this is a feature we do not use here anyway.
> 
> I chose 2.7 as a parting point because that is how it is  handled in
> infpy_read_memory in py-inferior.c.  Personally, I would leave it that
> way because with "buffer" exposed with Python 2.7 as well as Python
> 2.6 and below, I guess it gets more exposure and testing and won't
> suffer bit-rot as easily.
> 
> The patch is tested with Python 2.7 and Python 3.6.  I cannot test it
> with Python 2.6 but that should not be necessary as these two versions
> already check both different return types.

OK, that seems sensible for me indeed. Thanks for taking the time
to explain!

-- 
Joel

RE: MemoryView missing from Python 2.4 and 2.6

[Wiederhake, Tim]

Hi all,

Let me recap:

The python bindings I wrote break GDB compilation for Python 2.6 and below.

I wrote a patch: https://sourceware.org/ml/gdb-patches/2017-02/msg00712.html
which I later revised to this: https://sourceware.org/ml/gdb-patches/2017-03/msg00039.html

The revised patch was OK'd to push by Yao: https://sourceware.org/ml/gdb-patches/2017-03/msg00058.html
under the premise that Jose or I confirm that it works with Python 2.6.

Jose confirmed the first version: https://sourceware.org/ml/gdb-patches/2017-02/msg00715.html

As the second version does not change the actual code, I guess that is fine, too.

Joel seems to be fine with the general solution as well: https://sourceware.org/ml/gdb-patches/2017-03/msg00072.html

Do I need Eli's OK for the added line in the documentation?

Otherwise, it'd like to go ahead and push this patch.

Regards,
Tim

> -----Original Message-----
> From: Yao Qi [mailto:qiyaoltc@gmail.com]
> Sent: Tuesday, March 7, 2017 11:33 AM
> To: Wiederhake, Tim <tim.wiederhake@intel.com>
> Cc: Jose E. Marchesi <jose.marchesi@oracle.com>; gdb-
> patches@sourceware.org
> Subject: Re: MemoryView missing from Python 2.4 and 2.6
> 
> "Wiederhake, Tim" <tim.wiederhake@intel.com> writes:
> 
> > Thanks for the pointer. I've attached a revised version of the patch.
> 
> Hi Tim,
> Did you run py-record-btrace.xp with python 2.6? or probably Jose can help
> to run it with python 2.6.
> 
> If the test Tim added pass with both python 2.6 and python 3, your patch is
> OK.
> 
> --
> 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

Re: MemoryView missing from Python 2.4 and 2.6

[Yao Qi]

"Wiederhake, Tim" <tim.wiederhake@intel.com> writes:

> The revised patch was OK'd to push by Yao:
> https://sourceware.org/ml/gdb-patches/2017-03/msg00058.html
> under the premise that Jose or I confirm that it works with Python 2.6.

Tim and Jose,
Could you run the test added in this patch with python 2.6?  I can't find
a machine with python 2.6 installed.

-- 
Yao (齐尧)

Re: MemoryView missing from Python 2.4 and 2.6

[Jose E. Marchesi]

    
    > The revised patch was OK'd to push by Yao:
    > https://sourceware.org/ml/gdb-patches/2017-03/msg00058.html
    > under the premise that Jose or I confirm that it works with Python 2.6.
    
    Tim and Jose,
    Could you run the test added in this patch with python 2.6?  I can't find
    a machine with python 2.6 installed.

The revised patch fixes the build with python 2.6.6.

However, couldn't test the py-record-btrace.exp, because btrace is
disabled in sparc targets.

Re: MemoryView missing from Python 2.4 and 2.6

[Yao Qi]

"Wiederhake, Tim" <tim.wiederhake@intel.com> writes:

This patch is OK to go in, with the fix to the doc.

>  @defvar BtraceInstruction.data
>  A buffer with the raw instruction data.  May be @code{None} if the
> -instruction is a gap.
> +instruction is a gap.  In Python 3, the return value is a @code{memoryview}
> +object.
>  @end defvar

s/Python 3/@code{Python} 3/

-- 
Yao (齐尧)

Re: MemoryView missing from Python 2.4 and 2.6

[Yao Qi]

On Mon, Mar 20, 2017 at 9:04 AM, Yao Qi <qiyaoltc@gmail.com> wrote:
> "Wiederhake, Tim" <tim.wiederhake@intel.com> writes:
>
> This patch is OK to go in, with the fix to the doc.

As Eli comment
https://sourceware.org/ml/gdb-patches/2017-03/msg00344.html
"Python 3" is correct.  I withdraw my comment below.  Your patch
is OK to go in.

>
>>  @defvar BtraceInstruction.data
>>  A buffer with the raw instruction data.  May be @code{None} if the
>> -instruction is a gap.
>> +instruction is a gap.  In Python 3, the return value is a @code{memoryview}
>> +object.
>>  @end defvar
>
> s/Python 3/@code{Python} 3/
>

-- 
Yao (齐尧)