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)
On Nov 13, 2012, at 1:53 PM, Tom Tromey wrote:
>>>>>> "Paul" == <Paul_Koning@Dell.com> writes:
>
> ...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.
It seems that way. Python uses its own type internally if it has to, but uses wchar_t if that is suitable for storing Unicode in the way it wants to store it. And the PySys_SetArgv call is specifically defined to take wchar_t arguments -- not the Python Unicode type that is used elsewhere.
>
> 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.
Ok, I'll take out the exit and leave the error handling for a separate patch.
>
> 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.
Oops. I suppose I can do this via the "cleanup" mechanism, right?
paul
>
> Tom