This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Python 3 support, part 1 (non-testsuite part)
>>>>> "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