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

[Daniel Jacobowitz <dan@codesourcery.com>]

On Fri, Sep 10, 2010 at 03:25:45PM +0200, Serge CHATROUX wrote:
> I compile gdb 7.2 using MINGW tools and I enable the Python
> scripting support by giving the path to a Python for Windows install
> directory.

FYI, we've been building GDB for MinGW with Python support for six
months, and haven't encountered any of these problems.

I'm not surprised by the naming problems since I think our build
system rearranges the files.  But I am surprised that you had to
modify the GDB sources.

> I also modify the gdb/python sources to solve the following issues:
> 
> - Add some tests to disable Python scripting if Python is not available on the host at runtime. 
>   I detect if the PYTHONHOME variable is set. This enhancement is
>   maybe not useful for everybody.

What are you really detecting missing here?  The Python DLL must be
present; we link directly to it so GDB would not start if it wasn't.

> - I have to modify some gdb python files because the files 'python-function.c', python-cmd.c (...) define some 'static PyTypeObject'.
>   The field 'tp_new' of these static variables is statically initialized with the python 'PyType_GenericNew' function. 
>   In Windows port of Python, this function is declared as a dllimport one and cannot be copied at compilation time in a static variable.
>   For these files, I modified the source code
>       - to initialize the 'tp_new' fields to '0' in the static variables and
>       - to affect the proper 'PyType_GenericNew' value in the 'gdbpy_initialize_commands', 'gdbpy_initialize_frames' (...). 

This is the one that particularly puzzles me, we didn't have this problem.

> - When sourcing a Python script using 'source file.py' command, we cannot use 'PyRun_SimpleFile' because Python may not be compiled using the same MSVCRT DLL than GDB, so the FILE* stream will not be known in this DLL.
>   This generates an error when the MSVCRT will try to lock the file handle.

We did encounter this one; we solved it by making sure that GDB used
the same MSVCRT DLL.  But that solution is definitely not for
everyone, and I'd be happy enough to see GDB avoid this problem.



-- 
Daniel Jacobowitz
CodeSourcery