GDB 7.2 - Patch proposal for the use of GDB/Python scripts on MinGW

[Serge CHATROUX]

I confirm that the modification to avoid the affectation 'cmdpy_object_type.tp_new = PyType_GenericNew' is not supported by gcc version 3.4.2 (mingw-special) but is now supported by newer compiler (above a 4.3-based, I tried with gcc 4.5.0).

Thank you for the following information:

> Yeah, I don't know about that.  But, from
> http://docs.python.org/extending/newtypes.html:
>
>     We’d like to just assign this to the tp_new slot, but we can’t, for
>     portability sake, On some platforms or compilers, we can’t statically
>     initialize a structure member with a function defined in another C
>     module, so, instead, we’ll assign the tp_new slot in the module
>     initialization function just before calling PyType_Ready():
>
> So it seems your change might be needed at least sometimes.

I look at the Python documentation and I check that some standard modules of Python (sqlite) are conformed  to this rule but other don't (bz2, datetime).
I have to rewrite my patch because the affectation should be done before PyType_Ready() and I did it after!

> Serge> It could be great. I don't know the name of the Python scripting
> Serge> support maintainers. It could be great to have their feedback.
>
>  If you want to do it, it is fine.

I look at the initial list of developer that provides 'python.c' file:
	Vladimir Prus  <vladimir@codesourcery.com>
	Tom Tromey  <tromey@redhat.com>
	Thiago Jung Bauermann  <bauerman@br.ibm.com>
	Doug Evans  <dje@google.com>
I think that you and other maintainers will check my modifications carefully.

> Serge> I set this feature to solve an issue that I had on Linux:
> Serge> - I compiled Python support without the --enabled-shared support. 
>
> Ok.
>
> How does Python usually work in this setup?

Instead of embed the libpython.a, gdb look for the libpython2.6.so.1.0. 
I tried to compile with python --enabled-shared support because a user tells me that he have some issue in its environment.

> Serge> 	gdb
> Serge> 	'import site' failed; use -v for traceback
>
> It seems that we could catch this error and disable the python support at that time.
>
> This error is very misleading because "gdb -v" won't actually help.
> Ugh.

I think that this issue occurs in the '_initialize_python' function that executes a simple script to create a couple objects which are used for Python's stdout and stderr.
For instance, it occurs if I set the PYTHONHOME variable to an invalid value.

In order to submit a new corrected patch, should I start a new mail thread or do I continue to use this mail thread?

Regards