Re: [PATCH] 64-bit python support

Re: [PATCH] 64-bit python support

[Tom Tromey]

>>>>> "Ruben" == Ruben Van Boxem <vanboxem.ruben@gmail.com> writes:

Ruben> Attached is a patch that tells gdb-python to use the Py_InitModule4_64
Ruben> function instead of Py_InitModule for 64-bit builds.

I think this should not be needed.  I think the bug must lie somewhere
else.  I say this because Python's modsupport.h should already do this
renaming:

#if SIZEOF_SIZE_T != SIZEOF_INT
/* On a 64-bit system, rename the Py_InitModule4 so that 2.4
   modules cannot get loaded into a 2.5 interpreter */
#define Py_InitModule4 Py_InitModule4_64
#endif

Tom

Re: [PATCH] 64-bit python support

[Ruben Van Boxem]

2011/5/10 Tom Tromey <tromey@redhat.com>:
>>>>>> "Ruben" == Ruben Van Boxem <vanboxem.ruben@gmail.com> writes:
>
> Ruben> Attached is a patch that tells gdb-python to use the Py_InitModule4_64
> Ruben> function instead of Py_InitModule for 64-bit builds.
>
> I think this should not be needed.  I think the bug must lie somewhere
> else.  I say this because Python's modsupport.h should already do this
> renaming:
>
> #if SIZEOF_SIZE_T != SIZEOF_INT
> /* On a 64-bit system, rename the Py_InitModule4 so that 2.4
>   modules cannot get loaded into a 2.5 interpreter */
> #define Py_InitModule4 Py_InitModule4_64
> #endif

Ah, I didn't know this, that's indeed very handy, but the two
occurrences in my patch are actually still a call to Py_InitModule
without the "4". Then that probably needs to be patched instead?

Ruben

>
> Tom
>

Re: [PATCH] 64-bit python support

[Tom Tromey]

>>>>> "Ruben" == Ruben Van Boxem <vanboxem.ruben@gmail.com> writes:

Ruben> Ah, I didn't know this, that's indeed very handy, but the two
Ruben> occurrences in my patch are actually still a call to Py_InitModule
Ruben> without the "4". Then that probably needs to be patched instead?

No, there's a later define for that in modsupport.h:

#define Py_InitModule(name, methods) \
	Py_InitModule4(name, methods, (char *)NULL, (PyObject *)NULL, \
		       PYTHON_API_VERSION)

I think the thing to do is track down why the Python headers are picking
the wrong function name for you.

Tom

Re: [PATCH] 64-bit python support

[Ruben Van Boxem]

2011/5/10 Tom Tromey <tromey@redhat.com>:
>>>>>> "Ruben" == Ruben Van Boxem <vanboxem.ruben@gmail.com> writes:
>
> Ruben> Ah, I didn't know this, that's indeed very handy, but the two
> Ruben> occurrences in my patch are actually still a call to Py_InitModule
> Ruben> without the "4". Then that probably needs to be patched instead?
>
> No, there's a later define for that in modsupport.h:
>
> #define Py_InitModule(name, methods) \
>        Py_InitModule4(name, methods, (char *)NULL, (PyObject *)NULL, \
>                       PYTHON_API_VERSION)
>
> I think the thing to do is track down why the Python headers are picking
> the wrong function name for you.
>
> Tom
>

OK, found the problem. Apparantly the pyconfig.h header only defined
MS_WIN* when _MSC_VER is defined, which is obviously not the case for
mingw-w64. I guess people attempted fixing it here
(http://bugs.python.org/issue4709), but the patch never landed. Sorry
for the noise here. I'll just add "-DMS_WIN64" to the CFLAGS for GDB.
Pretty lame of Python devs though, with all the work put into the tiny
and overly correct patch. I'll ping them there and work around this
locally.

Thanks for the quick response here!

Ruben

[PATCH] 64-bit python support

[Ruben Van Boxem]

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

Hi,

Attached is a patch that tells gdb-python to use the Py_InitModule4_64
function instead of Py_InitModule for 64-bit builds.

The latter is not in the official Python x64 Windows dll, and from
looking around on the net, neither is it present on 64-bit linux
Python libraries (can't say that for sure though). This patch allows a
successful build with mingw-w64.

Here is a link to the rationale for the different function name on the
Python website:
http://www.python.org/dev/peps/pep-0353/#specification

The patch was made using the 7.3 branch. Please comment on and/or OK
this patch. Thanks!

Ruben

[-- Attachment #2: gdb-python64.patch --]
[-- Type: text/x-patch, Size: 1014 bytes --]

diff --git a/gdb/python/py-evts.c b/gdb/python/py-evts.c
index 50c05f3..3a541b4 100644
--- a/gdb/python/py-evts.c
+++ b/gdb/python/py-evts.c
@@ -44,8 +44,11 @@ add_new_registry (eventregistry_object **registryp, char *name)
 void
 gdbpy_initialize_py_events (void)
 {
+#if defined(__x86_64__)
+  gdb_py_events.module = Py_InitModule4_64 ("events", NULL);
+#else
   gdb_py_events.module = Py_InitModule ("events", NULL);
-
+#endif
   if (!gdb_py_events.module)
     goto fail;
 
diff --git a/gdb/python/python.c b/gdb/python/python.c
index 90d5dc8..3323433 100644
--- a/gdb/python/python.c
+++ b/gdb/python/python.c
@@ -1013,7 +1013,11 @@ Enables or disables printing of Python stack traces."),
   Py_Initialize ();
   PyEval_InitThreads ();
 
+#if defined(__x86_64__)
+  gdb_module = Py_InitModule4_64 ("gdb", GdbMethods);
+#else
   gdb_module = Py_InitModule ("gdb", GdbMethods);
+#endif
 
   /* The casts to (char*) are for python 2.4.  */
   PyModule_AddStringConstant (gdb_module, "VERSION", (char*) version);