[patchv2] Fix Python 3 build error on 32-bit hosts

Message ID 20150204192028.GA12310@host1.jankratochvil.net
State New, archived
Headers

Commit Message

Jan Kratochvil Feb. 4, 2015, 7:20 p.m. UTC
  On Wed, 04 Feb 2015 19:58:18 +0100, Pedro Alves wrote:
> I agree with Paul here.  I think checking Python version is sufficient.

I should point out that version checking is error prone to distro backports.


> I'd be fine with providing a fallback Py_hash_t in python/python-internal.h,
> where we already do a series of fallback definitions and fixes for older
> Python, such as e.g. Py_ssize_t.

Done.


Jan
gdb/
2015-02-04  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* python/python-internal.h (Py_hash_t): Define it for Python <3.2.
	* python/py-value.c (valpy_fetch_lazy): Use it.  Remove cast to the
	return type.
  

Comments

Pedro Alves Feb. 4, 2015, 7:27 p.m. UTC | #1
On 02/04/2015 08:20 PM, Jan Kratochvil wrote:
> On Wed, 04 Feb 2015 19:58:18 +0100, Pedro Alves wrote:
>> I agree with Paul here.  I think checking Python version is sufficient.
> 
> I should point out that version checking is error prone to distro backports.

Distros will be backporting Python fixes, not API/ABI breaking changes.

>> I'd be fine with providing a fallback Py_hash_t in python/python-internal.h,
>> where we already do a series of fallback definitions and fixes for older
>> Python, such as e.g. Py_ssize_t.
> 
> Done.

OK.

Thanks,
Pedro Alves
  
Jan Kratochvil Feb. 4, 2015, 7:34 p.m. UTC | #2
On Wed, 04 Feb 2015 20:27:16 +0100, Pedro Alves wrote:
> Distros will be backporting Python fixes, not API/ABI breaking changes.

Adding a new typedef (in the library namespace) I do not find as an API
breakage (for correctly written applications).


> OK.

Checked in:
	881d5d5db08ee6b343e1f1fc560d785fed29428e


Thanks,
Jan
  
Pedro Alves Feb. 4, 2015, 7:41 p.m. UTC | #3
On 02/04/2015 08:34 PM, Jan Kratochvil wrote:
> On Wed, 04 Feb 2015 20:27:16 +0100, Pedro Alves wrote:
>> Distros will be backporting Python fixes, not API/ABI breaking changes.
> 
> Adding a new typedef (in the library namespace) I do not find as an API
> breakage (for correctly written applications).

Changing the tp_hash's callback type is, as clearly evidenced by
the necessity of this fix.

Thanks,
Pedro Alves
  
Phil Muldoon Feb. 4, 2015, 7:51 p.m. UTC | #4
On 04/02/15 19:34, Jan Kratochvil wrote:
> On Wed, 04 Feb 2015 20:27:16 +0100, Pedro Alves wrote:
>> Distros will be backporting Python fixes, not API/ABI breaking changes.
> Adding a new typedef (in the library namespace) I do not find as an API
> breakage (for correctly written applications).
It's not. The API promise only applies to explicitly exported APIs and objects from  GDB Python

Cheers

Phil
  
Paul_Koning@Dell.com Feb. 4, 2015, 9:06 p.m. UTC | #5
> On Feb 4, 2015, at 2:20 PM, Jan Kratochvil <jan.kratochvil@redhat.com> wrote:
> 
> On Wed, 04 Feb 2015 19:58:18 +0100, Pedro Alves wrote:
>> I agree with Paul here.  I think checking Python version is sufficient.
> 
> I should point out that version checking is error prone to distro backports.

That’s true in many cases.  But here we’re dealing with a documented API difference, and the definition explicitly states that the change is associated with a particular Python version (core version, not distro).

	paul
  

Patch

diff --git a/gdb/python/python-internal.h b/gdb/python/python-internal.h
index 0ee8544..23d4755 100644
--- a/gdb/python/python-internal.h
+++ b/gdb/python/python-internal.h
@@ -169,6 +169,10 @@  typedef unsigned long gdb_py_ulongest;
 
 #endif /* HAVE_LONG_LONG */
 
+#if PY_VERSION_HEX < 0x03020000
+typedef long Py_hash_t;
+#endif
+
 /* Python 2.6 did not wrap Py_DECREF in 'do {...} while (0)', leading
    to 'suggest explicit braces to avoid ambiguous ‘else’' gcc errors.
    Wrap it ourselves, so that callers don't need to care.  */
diff --git a/gdb/python/py-value.c b/gdb/python/py-value.c
index 4c4d36e..5a13777 100644
--- a/gdb/python/py-value.c
+++ b/gdb/python/py-value.c
@@ -895,10 +895,10 @@  valpy_fetch_lazy (PyObject *self, PyObject *args)
 
 /* Calculate and return the address of the PyObject as the value of
    the builtin __hash__ call.  */
-static long
+static Py_hash_t
 valpy_hash (PyObject *self)
 {
-  return (long) (intptr_t) self;
+  return (intptr_t) self;
 }
 
 enum valpy_opcode