Re: [PATCH] Python 3 support, part 1 (non-testsuite part)

[Tom Tromey <tromey@redhat.com>]

>>>>> "Paul" ==   <Paul_Koning@Dell.com> writes:

Paul> Because PyModule_Create returns a new reference, while Py_InitModule
Paul> returns a borrowed reference (bletch).

Oh, yeah, it is obvious now :)  Thanks.

[...]
Paul> Or Py_TYPE (self)->tp_free (self) -- less change from the existing
Paul> code.  That argument doesn't need a cast, the signature is tp_free
Paul> (void *).

Oops, yeah, that is what I meant.

Paul> +  wchar_t *progname_copy;

Tom> Can we really assume a working wchar_t?

Paul> Yes, you'd expect a configure check or the like.  But the header files
Paul> for Python reference that type without any checks that I can see.
Paul> Similarly mbstowcs().  It looks like you can't built Python 3 if those
Paul> aren't defined (which makes some sense -- how else could you build a
Paul> program that uses Unicode for all its strings?).

Ok, I think that is sufficient.
If Python ever adds checks, and we hit such a such a system, we can fix
it up then.

It is a little weird since wchar_t isn't guaranteed to have anything to
do with Unicode.  But I assume they know what they are doing.

Paul> Ok.  That code was adapted from Python 3 code which does it this way.
Paul> The existing code in python.c calls a whole string of API calls (like
Paul> PyModule_AddStringConstant) without checking the error status from any
Paul> of them.  Should I add those, with the failure action being to disable
Paul> Python support in GDB?

I'm not sure what to do about those.  I guess failing gracefully would
be better than what we do now.

FWIW I'm not sure we really have a way to disable Python at runtime yet.
And to be clear, I don't expect you to add this as part of your patch.
Mostly I just want to avoid an 'exit' on a failure to initialize -- it
is better for gdb to try to limp along in this situation.

Paul> Index: py-inferior.c
[...]
Paul>    GDB_PY_HANDLE_EXCEPTION (except);
 
Paul> +#ifdef IS_PY3K
Paul> +  PyBuffer_Release (pybuf);
Paul> +#endif

GDB_PY_HANDLE_EXCEPTION can return, so cleaning up has to be handled
there as well somehow.

Maybe this is an issue in the other spot, too, I couldn't tell
immediately.

Tom