Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Serge CHATROUX <serge.chatroux@st.com>
To: Tom Tromey <tromey@redhat.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: RE: GDB 7.2 - Patch proposal for the use of GDB/Python scripts on MinGW
Date: Mon, 13 Sep 2010 17:41:00 -0000	[thread overview]
Message-ID: <A42F0F6AD104734CAC7D6B1963F60DD80116E3AF5194@SAFEX1MAIL2.st.com> (raw)
In-Reply-To: <4C8DE078.4090309@st.com>

> Do you have a copyright assignment in place for gdb?
> If not, email me and we can get the process started.

Yes (I work with Christophe Lyon).

> It is generally better if you send separate patches for each thing.
> Also, we like submissions to include a ChangeLog entry... see src/gdb/CONTRIBUTE for various other things.

I will split the patch into severals.
I also replied (directly) to Daniel Jacobowitz comments and wait its feedback.

> Serge> + #ifdef __MINGW32__
> Serge> +   /*
> Serge> + 	 I have to modify some gdb python files because the files
> 'python-function.c', python-cmd.c and python-frame.c define some 'static PyTypeObject'.
> Serge> +      The field 'tp_new' of these static variables statically
> initialized with the python 'PyType_GenericNew' function.
> Serge> +      In Windows port of Python, this function is declared as a dllimport function and can not be copied at compilation time in a static variable.
> Serge> +      For these 3 files, I modify 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' and 'gdbpy_initialize_functions'.
> Serge> +   */
> Serge> +   cmdpy_object_type.tp_new = PyType_GenericNew; #endif
>
> Just make your patch do this unconditionally on all hosts, with a little (one line -- not as long as what you have above) comment explaining where it is needed.  I think that is clearer than using #ifdef all over.

I can reduce the comment size.
I do not know how to avoid the '#if __MINGW32__' because this modification is not needed for other systems (Linux, cygwin).
It seems that Daniel Jacobowitz succeed in compiling gdb over MINGW without this modification.

> Serge> + #ifdef __MINGW32__
> Serge> +   {
> Serge> +     /* We can not use 'PyRun_SimpleFile' because Python may not be compiled using the same MSVCRT DLL than GDB
> Serge> +        so the FILE* stream will not be known in this DLL. This generate an error when the MSVCRT will try to lock the file handle. */
>
> These lines are too long.  In GDB we wrap at column 79 or so; the GNU coding standards cover this.

OK.

> Serge> +     PyObject* PyFileObject = PyFile_FromString( (char*) file, "r");
>
> The spacing is different from our standard.  It should look like:
> 
>      PyObject *file_object = PyFile_FromString ((char *) file, "r");
>
> Perhaps this code and some surrounding code should be refactored so that we can just avoid FILE* and use the same code path on all hosts.

It could be great. I don't know the name of the Python scripting support maintainers. It could be great to have their feedback.

> Serge> +   /* Do not enable python scripting if the PYTHONHOME variable is undefined */
> Serge> + #ifdef HAVE_PYTHON
> Serge> +   if (getenv( "PYTHONHOME") == NULL)
> Serge> +     {
> 
> This doesn't seem correct to me.
> 
> It definitely isn't ok for the Linux distro case.  There, Python comes with the system and basically nobody sets PYTHONHOME.
> 
> It isn't clear to me that it is always correct even on MinGW.  Couldn't someone ship a pre-built GDB plus a pre-built Python in the same tree, and expect it to work properly?
>
> What is the failure mode here?  GDB finds the python DLL but still somehow doesn't work?

I will remove this part of the patch ($PYTHONHOME detection...), it is not relevant for a standard version.
I set this feature to solve an issue that I had on Linux:
- I compiled Python support without the --enabled-shared support. 
- At gdb compilation time, the Python library was embed (linked with libpython2.6.a not the shared library).
When I use the gdb program on a Linux host on which Python is not installed or without defined PYTHONPATH variable, I got the following message:
	gdb
	'import site' failed; use -v for traceback
	GNU gdb (GDB) 7.2
	Copyright (C) 2010 Free Software Foundation, Inc.
By checking the PYTHONHOME variable, I tried to check that the user set a valid Python environment. 


Regards



  reply	other threads:[~2010-09-13 11:44 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-10 13:58 Serge CHATROUX
2010-09-10 15:47 ` Tom Tromey
2010-09-13 17:09   ` Christophe Lyon
2010-09-13 17:41     ` Serge CHATROUX [this message]
2010-09-13 19:15       ` Tom Tromey
2010-09-17 14:42         ` Serge CHATROUX
2010-09-21 22:50           ` Tom Tromey
2010-09-11 16:34 ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=A42F0F6AD104734CAC7D6B1963F60DD80116E3AF5194@SAFEX1MAIL2.st.com \
    --to=serge.chatroux@st.com \
    --cc=gdb-patches@sourceware.org \
    --cc=tromey@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox