tree 137024a4825810728dc9a323fd5eee9ad078f309
parent 22a7a2d12a81a4c4521d1d9996d06b7abf315acc
author Tom de Vries <tdevries@suse.de> 1733262580 +0100
committer Tom de Vries <tdevries@suse.de> 1733262580 +0100

[gdb/python] Factor out and refactor py_initialize

Function do_start_initialization has a large part dedicated to initializing
the python interpreter, as opposed to the rest of the function where
gdb-specific python support is initialized.

Factor out this part, as new function py_initialize, and rename the existing
py_initialize to py_initialize_catch_abort.

Refactor the new function py_initialize by getting rid of the nested:
...
 #ifdef WITH_PYTHON_PATH
 #if PY_VERSION_HEX < 0x030a0000
 #else
 #endif
 #else
 #endif
...

In particular, this changes behaviour for the "!defined (WITH_PYTHON_PATH)"
case.

For the "defined (WITH_PYTHON_PATH)" case, we've started using
Py_InitializeFromConfig () for PY_VERSION_HEX >= 0x030a0000 to deal with the
deprecation of Py_SetProgramName in 3.11.

For the "!defined (WITH_PYTHON_PATH)" case, we don't use Py_SetProgramName so
we stuck with Py_Initialize ().

However, in 3.12 Py_DontWriteBytecodeFlag and Py_IgnoreEnvironmentFlag got
deprecated and also here we need Py_InitializeFromConfig () to deal with this,
but the "!defined (WITH_PYTHON_PATH)" case didn't get updated.

This should be taken care of, now that we have this behavior:
- for PY_VERSION_HEX < 0x030a0000 we use Py_Initialize
- for PY_VERSION_HEX >= 0x030a0000 we use Py_InitializeFromConfig

I'm not sure how to test the "!defined (WITH_PYTHON_PATH)" though.

Tested on aarch64-linux.

Approved-By: Tom Tromey <tom@tromey.com>