Make GDB build with python 2.4 again.

Make GDB build with python 2.4 again.

[Pedro Alves]

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

gcc -g -O2   -I. -I../../head/gdb -I../../head/gdb/config -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H -I../../head/gdb/../include/opcode -I../../head/gdb/../readline/.. -I../bfd -I../../head/gdb/../bfd -I../../head/gdb/../include -I../libdecnumber -I../../head/gdb/../libdecnumber  -I../../head/gdb/gnulib -Ignulib  -DMI_OUT=1  -DTUI=1  -Wall -Wdeclaration-after-statement -Wpointer-arith -Wformat-nonliteral -Wno-unused -Wno-switch -Wno-char-subscripts -Werror -c -o python-value.o -MT python-value.o -MMD -MP -MF .deps/python-value.Tpo -fno-strict-aliasing -DNDEBUG -fwrapv ../../head/gdb/python/python-value.c
../../head/gdb/python/python-value.c:100: warning: initialization from incompatible pointer type
make: *** [python-value.o] Error 1

/usr/include/python2.4/object.h

 typedef int (*inquiry)(PyObject *);

 typedef struct {
	inquiry mp_length;
	binaryfunc mp_subscript;
	objobjargproc mp_ass_subscript;
 } PyMappingMethods;

/usr/include/python2.5/object.h

 typedef Py_ssize_t (*lenfunc)(PyObject *);

 typedef struct {
	lenfunc mp_length;
	binaryfunc mp_subscript;
	objobjargproc mp_ass_subscript;
 } PyMappingMethods;

I'm checking in the attached fix.  I get 95 expected passes with
both 2.4 and 2.5.

-- 
Pedro Alves

[-- Attachment #2: python.diff --]
[-- Type: text/x-diff, Size: 5947 bytes --]

2008-10-19  Pedro Alves  <pedro@codesourcery.com>

	* python/python-value.c (value_object_methods)
	(value_object_as_number, value_object_as_mapping): Move to bottom
	of file.
	(valpy_dealloc, valpy_new, valpy_length, valpy_getitem)
	(valpy_setitem, valpy_str, valpy_add, valpy_subtract)
	(valpy_multiply, valpy_divide, valpy_remainder, valpy_power)
	(valpy_negative, valpy_positive, valpy_absolute, valpy_nonzero)
	(valpy_richcompare, valpy_dereference): Don't forward-declare.
	(valpy_length) [HAVE_LIBPYTHON2_4]: Change return type to `int'.

---
 gdb/python/python-value.c |  139 ++++++++++++++++++++--------------------------
 1 file changed, 61 insertions(+), 78 deletions(-)

Index: src/gdb/python/python-value.c
===================================================================
--- src.orig/gdb/python/python-value.c	2008-10-19 20:27:15.000000000 +0100
+++ src/gdb/python/python-value.c	2008-10-19 20:28:25.000000000 +0100
@@ -57,84 +57,6 @@ typedef struct {
   int owned_by_gdb;
 } value_object;
 
-static void valpy_dealloc (PyObject *obj);
-static PyObject *valpy_new (PyTypeObject *subtype, PyObject *args,
-			    PyObject *keywords);
-static Py_ssize_t valpy_length (PyObject *self);
-static PyObject *valpy_getitem (PyObject *self, PyObject *key);
-static int valpy_setitem (PyObject *self, PyObject *key, PyObject *value);
-static PyObject *valpy_str (PyObject *self);
-static PyObject *valpy_add (PyObject *self, PyObject *other);
-static PyObject *valpy_subtract (PyObject *self, PyObject *other);
-static PyObject *valpy_multiply (PyObject *self, PyObject *other);
-static PyObject *valpy_divide (PyObject *self, PyObject *other);
-static PyObject *valpy_remainder (PyObject *self, PyObject *other);
-static PyObject *valpy_power (PyObject *self, PyObject *other, PyObject *unused);
-static PyObject *valpy_negative (PyObject *self);
-static PyObject *valpy_positive (PyObject *self);
-static PyObject *valpy_absolute (PyObject *self);
-static int valpy_nonzero (PyObject *self);
-static PyObject *valpy_richcompare (PyObject *self, PyObject *other, int op);
-static PyObject *valpy_dereference (PyObject *self, PyObject *args);
-
-static PyMethodDef value_object_methods[] = {
-  { "dereference", valpy_dereference, METH_NOARGS, "Dereferences the value." },
-  {NULL}  /* Sentinel */
-};
-
-static PyNumberMethods value_object_as_number = {
-  valpy_add,
-  valpy_subtract,
-  valpy_multiply,
-  valpy_divide,
-  valpy_remainder,
-  NULL,			      /* nb_divmod */
-  valpy_power,		      /* nb_power */
-  valpy_negative,	      /* nb_negative */
-  valpy_positive,	      /* nb_positive */
-  valpy_absolute,	      /* nb_absolute */
-  valpy_nonzero		      /* nb_nonzero */
-};
-
-static PyMappingMethods value_object_as_mapping = {
-  valpy_length,
-  valpy_getitem,
-  valpy_setitem
-};
-
-PyTypeObject value_object_type = {
-  PyObject_HEAD_INIT (NULL)
-  0,				  /*ob_size*/
-  "gdb.Value",			  /*tp_name*/
-  sizeof (value_object),	  /*tp_basicsize*/
-  0,				  /*tp_itemsize*/
-  valpy_dealloc,		  /*tp_dealloc*/
-  0,				  /*tp_print*/
-  0,				  /*tp_getattr*/
-  0,				  /*tp_setattr*/
-  0,				  /*tp_compare*/
-  0,				  /*tp_repr*/
-  &value_object_as_number,	  /*tp_as_number*/
-  0,				  /*tp_as_sequence*/
-  &value_object_as_mapping,	  /*tp_as_mapping*/
-  0,				  /*tp_hash */
-  0,				  /*tp_call*/
-  valpy_str,			  /*tp_str*/
-  0,				  /*tp_getattro*/
-  0,				  /*tp_setattro*/
-  0,				  /*tp_as_buffer*/
-  Py_TPFLAGS_DEFAULT | Py_TPFLAGS_CHECKTYPES,	/*tp_flags*/
-  "GDB value object",		  /* tp_doc */
-  0,				  /* tp_traverse */
-  0,				  /* tp_clear */
-  valpy_richcompare,		  /* tp_richcompare */
-  0,				  /* tp_weaklistoffset */
-  0,				  /* tp_iter */
-  0,				  /* tp_iternext */
-  value_object_methods		  /* tp_methods */
-};
-
-
 /* Called by the Python interpreter when deallocating a value object.  */
 static void
 valpy_dealloc (PyObject *obj)
@@ -206,7 +128,11 @@ valpy_dereference (PyObject *self, PyObj
   return value_to_value_object (res_val);
 }
 
+#ifdef HAVE_LIBPYTHON2_4
+static int
+#else
 static Py_ssize_t
+#endif
 valpy_length (PyObject *self)
 {
   /* We don't support getting the number of elements in a struct / class.  */
@@ -686,4 +612,61 @@ gdbpy_initialize_values (void)
   values_in_python = NULL;
 }
 
+static PyMethodDef value_object_methods[] = {
+  { "dereference", valpy_dereference, METH_NOARGS, "Dereferences the value." },
+  {NULL}  /* Sentinel */
+};
+
+static PyNumberMethods value_object_as_number = {
+  valpy_add,
+  valpy_subtract,
+  valpy_multiply,
+  valpy_divide,
+  valpy_remainder,
+  NULL,			      /* nb_divmod */
+  valpy_power,		      /* nb_power */
+  valpy_negative,	      /* nb_negative */
+  valpy_positive,	      /* nb_positive */
+  valpy_absolute,	      /* nb_absolute */
+  valpy_nonzero		      /* nb_nonzero */
+};
+
+static PyMappingMethods value_object_as_mapping = {
+  valpy_length,
+  valpy_getitem,
+  valpy_setitem
+};
+
+PyTypeObject value_object_type = {
+  PyObject_HEAD_INIT (NULL)
+  0,				  /*ob_size*/
+  "gdb.Value",			  /*tp_name*/
+  sizeof (value_object),	  /*tp_basicsize*/
+  0,				  /*tp_itemsize*/
+  valpy_dealloc,		  /*tp_dealloc*/
+  0,				  /*tp_print*/
+  0,				  /*tp_getattr*/
+  0,				  /*tp_setattr*/
+  0,				  /*tp_compare*/
+  0,				  /*tp_repr*/
+  &value_object_as_number,	  /*tp_as_number*/
+  0,				  /*tp_as_sequence*/
+  &value_object_as_mapping,	  /*tp_as_mapping*/
+  0,				  /*tp_hash */
+  0,				  /*tp_call*/
+  valpy_str,			  /*tp_str*/
+  0,				  /*tp_getattro*/
+  0,				  /*tp_setattro*/
+  0,				  /*tp_as_buffer*/
+  Py_TPFLAGS_DEFAULT | Py_TPFLAGS_CHECKTYPES,	/*tp_flags*/
+  "GDB value object",		  /* tp_doc */
+  0,				  /* tp_traverse */
+  0,				  /* tp_clear */
+  valpy_richcompare,		  /* tp_richcompare */
+  0,				  /* tp_weaklistoffset */
+  0,				  /* tp_iter */
+  0,				  /* tp_iternext */
+  value_object_methods		  /* tp_methods */
+};
+
 #endif /* HAVE_PYTHON */

Re: Make GDB build with python 2.4 again.

[Paul Pluzhnikov]

On Sun, Oct 19, 2008 at 1:18 PM, Pedro Alves <pedro@codesourcery.com> wrote:

> I'm checking in the attached fix.  I get 95 expected passes with
> both 2.4 and 2.5.

Meanwhile, on 'archer-tromey-python':

$ git show 083493c09e01a8e67057b890689883ddbd6bc830
commit 083493c09e01a8e67057b890689883ddbd6bc830
Author: Paul Pluzhnikov <ppluzhnikov@google.com>
Date:   Mon Oct 13 15:54:49 2008 -0700

    2008-10-13  Paul Pluzhnikov  <ppluzhnikov@google.com>

        * python/python-internal.h: Fix 64-bit compilation with python2.4

diff --git a/gdb/python/python-internal.h b/gdb/python/python-internal.h
index 5896907..207d3e4 100644
--- a/gdb/python/python-internal.h
+++ b/gdb/python/python-internal.h
@@ -33,8 +33,11 @@

 #if HAVE_LIBPYTHON2_4
 #include "python2.4/Python.h"
-/* Py_ssize_t is not defined until 2.5.  */
-typedef Py_intptr_t Py_ssize_t;
+/* Py_ssize_t is not defined until 2.5.
+   Logical type for Py_ssize_t is Py_intptr_t, but that fails in 64-bit
+   compilation due to several apparent mistakes in python2.4 API, so we
+   use 'int' instead.  */
+typedef int Py_ssize_t;
 #elif HAVE_LIBPYTHON2_5
 #include "python2.5/Python.h"
 #elif HAVE_LIBPYTHON2_6



Note that in current gdb/python sources, additional changes
are required for python2.4 if Py_ssize_t isn't fixed as above ...

> 2008-10-19  Pedro Alves  <pedro@codesourcery.com>
>
>        * python/python-value.c (value_object_methods)
>        (value_object_as_number, value_object_as_mapping): Move to bottom
>        of file.

Why?


Thanks,
-- 
Paul Pluzhnikov

Re: Make GDB build with python 2.4 again.

[Pedro Alves]

On Sunday 19 October 2008 23:46:58, Paul Pluzhnikov wrote:
> On Sun, Oct 19, 2008 at 1:18 PM, Pedro Alves <pedro@codesourcery.com> wrote:
> 
> > I'm checking in the attached fix.  I get 95 expected passes with
> > both 2.4 and 2.5.
> 
> Meanwhile, on 'archer-tromey-python':

Sorry, but if you know something is broken in code that's in the FSF
tree, you should post a patch there.  You can't expect me to track what's
going on the archer branches.

> 
> $ git show 083493c09e01a8e67057b890689883ddbd6bc830
> commit 083493c09e01a8e67057b890689883ddbd6bc830
> Author: Paul Pluzhnikov <ppluzhnikov@google.com>
> Date:   Mon Oct 13 15:54:49 2008 -0700
> 
>     2008-10-13  Paul Pluzhnikov  <ppluzhnikov@google.com>
> 
>         * python/python-internal.h: Fix 64-bit compilation with python2.4
> 
> diff --git a/gdb/python/python-internal.h b/gdb/python/python-internal.h
> index 5896907..207d3e4 100644
> --- a/gdb/python/python-internal.h
> +++ b/gdb/python/python-internal.h
> @@ -33,8 +33,11 @@
> 
>  #if HAVE_LIBPYTHON2_4
>  #include "python2.4/Python.h"
> -/* Py_ssize_t is not defined until 2.5.  */
> -typedef Py_intptr_t Py_ssize_t;
> +/* Py_ssize_t is not defined until 2.5.
> +   Logical type for Py_ssize_t is Py_intptr_t, but that fails in 64-bit
> +   compilation due to several apparent mistakes in python2.4 API, so we
> +   use 'int' instead.  */
> +typedef int Py_ssize_t;
>  #elif HAVE_LIBPYTHON2_5
>  #include "python2.5/Python.h"
>  #elif HAVE_LIBPYTHON2_6
>
> 
> Note that in current gdb/python sources, additional changes
> are required for python2.4 if Py_ssize_t isn't fixed as above ...
> 

That looks strange, since ssize_t isn't usually the same size
of int.  Well, if this works for you, and you think you aren't
going to trip on that further on, then by all means, post a patch
at gdb-patches.  In the mean time, every one else can continue
building FSF GDB.

> > 2008-10-19  Pedro Alves  <pedro@codesourcery.com>
> >
> >        * python/python-value.c (value_object_methods)
> >        (value_object_as_number, value_object_as_mapping): Move to bottom
> >        of file.
> 
> Why?

To avoid all the forward references, so that we don't have to change
two places whenever an interface changes, or things like these happen.

-- 
Pedro Alves

Re: Make GDB build with python 2.4 again.

[Tom Tromey]

>>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:

>> Meanwhile, on 'archer-tromey-python':

Pedro> Sorry, but if you know something is broken in code that's in the FSF
Pedro> tree, you should post a patch there.  You can't expect me to track what's
Pedro> going on the archer branches.

That seems reasonable.  In this case, I didn't consider that the patch
might be useful upstream, or I would have asked Paul to send it
upstream.  Sorry about that.

>> Note that in current gdb/python sources, additional changes
>> are required for python2.4 if Py_ssize_t isn't fixed as above ...

Pedro> That looks strange, since ssize_t isn't usually the same size
Pedro> of int.

My belief is that Py_ssize_t is a 2.5 introduction, and places using
Py_ssize_t used to use int.  That is why the patch was written the way
it was.

>> > 2008-10-19  Pedro Alves  <pedro@codesourcery.com>
>> >
>> >        * python/python-value.c (value_object_methods)
>> >        (value_object_as_number, value_object_as_mapping): Move to bottom
>> >        of file.

Paul> Why?

Pedro> To avoid all the forward references, so that we don't have to change
Pedro> two places whenever an interface changes, or things like these happen.

This is an issue -- a minor one -- for three reasons.

First, in general, it is better to commit code rearrangements and bug
fixes as separate patches.

Second, in this particular instance, this code is actively being
worked on separately and being merged in.  Changes to the trunk mean
back-porting the changes and redoing the patch branch -- adding work
for, IMO, little gain.  This is related to the first point in that
this patch has to be edited before backporting.

Finally, there is nothing to say that the preferred gdb style is to
avoid forward declarations.  So, we picked a style we liked -- not
unintentionally, at least on my part, but because I like having the
"class definition" at the top, followed by method implementations,
followed by the initialization code.  All the python code follows this
outline.

I'll look at moving this change to the python branch tomorrow (unless
someone gets there first).  If you want all the forward declarations
removed from the python code, please let me know, and I'll implement
that on the branch as well.

Tom

Re: Make GDB build with python 2.4 again.

[Pedro Alves]

On Monday 20 October 2008 00:40:40, Tom Tromey wrote:
> >>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:

> >> Note that in current gdb/python sources, additional changes
> >> are required for python2.4 if Py_ssize_t isn't fixed as above ...
> 
> Pedro> That looks strange, since ssize_t isn't usually the same size
> Pedro> of int.
> 
> My belief is that Py_ssize_t is a 2.5 introduction, and places using
> Py_ssize_t used to use int.  That is why the patch was written the way
> it was.
> 

Ok then.

> >> > 2008-10-19  Pedro Alves  <pedro@codesourcery.com>
> >> >
> >> >        * python/python-value.c (value_object_methods)
> >> >        (value_object_as_number, value_object_as_mapping): Move to bottom
> >> >        of file.
> 
> Paul> Why?
> 
> Pedro> To avoid all the forward references, so that we don't have to change
> Pedro> two places whenever an interface changes, or things like these happen.
> 

> This is an issue -- a minor one -- for three reasons.
> 

> First, in general, it is better to commit code rearrangements and bug
> fixes as separate patches.
> 

I tend to follow that trend, as you can see by my latest commits.
In this case, I wasn't that it was annoying me visually.  It was
either move, or add two ifdefs.  :-/  Exacly the reason we should
avoid forward declarations.

> Finally, there is nothing to say that the preferred gdb style is to
> avoid forward declarations.  So, we picked a style we liked -- not
> unintentionally, at least on my part, but because I like having the
> "class definition" at the top, followed by method implementations,
> followed by the initialization code.  All the python code follows this
> outline.

If you look at most other cases where we use a structure holding
function pointers, like e.g., target_ops instances, languages, debug
info readers, you'll see that we define the code, and register the
function pointers at the end of the file.  For new code, we should
try avoiding them, it's just unneeded extra work to adjust them
when interfaces change.

> 
> I'll look at moving this change to the python branch tomorrow (unless
> someone gets there first).  If you want all the forward declarations
> removed from the python code, please let me know, and I'll implement
> that on the branch as well.

I'd prefer that similar new code avoids forward declarations, yes.

However, I'm also fine with reverting my last change, and
applying Paul's if that's less work for you.  Heck, that's why we
use a revision control system.

-- 
Pedro Alves

Re: Make GDB build with python 2.4 again.

[Tom Tromey]

>>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:

Pedro> For new code, we should try avoiding them, it's just unneeded
Pedro> extra work to adjust them when interfaces change.

Would you mind updating gdbint.texinfo to say that?

Pedro> However, I'm also fine with reverting my last change, and
Pedro> applying Paul's if that's less work for you.  Heck, that's why we
Pedro> use a revision control system.

Forward!  I'll just fix the branch.

Tom

Re: Make GDB build with python 2.4 again.

[Pedro Alves]

On Monday 20 October 2008 01:11:40, Tom Tromey wrote:
> >>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:
> 
> Pedro> For new code, we should try avoiding them, it's just unneeded
> Pedro> extra work to adjust them when interfaces change.
> 
> Would you mind updating gdbint.texinfo to say that?

That sounds fair.  I'll do that.

> Pedro> However, I'm also fine with reverting my last change, and
> Pedro> applying Paul's if that's less work for you.  Heck, that's why we
> Pedro> use a revision control system.
> 
> Forward!  I'll just fix the branch.
> 

Thanks.

-- 
Pedro Alves

Re: Make GDB build with python 2.4 again.

[Tom Tromey]

>>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:

>> Would you mind updating gdbint.texinfo to say that?

Pedro> That sounds fair.  I'll do that.

Thanks.

Pedro> However, I'm also fine with reverting my last change, and
Pedro> applying Paul's if that's less work for you.  Heck, that's why we
Pedro> use a revision control system.

>> Forward!  I'll just fix the branch.

Pedro> Thanks.

I pushed the changes to python branch.

Tom