[gdb/python] Use PyConfig for python 3.9

On ppc64le-linux (AlmaLinux 9.6) with python 3.9 and test-case
gdb.python/py-failed-init.exp I run into:
...
builtin_spawn $gdb -nw -nx -q -iex set height 0 -iex set width 0 \
  -data-directory $build/gdb/data-directory -iex set interactive-mode on^M
Python path configuration:^M
  PYTHONHOME = 'foo'^M
  PYTHONPATH = (not set)^M
  program name = '/usr/bin/python'^M
  isolated = 0^M
  environment = 1^M
  user site = 1^M
  import site = 1^M
  sys._base_executable = '/usr/bin/python'^M
  sys.base_prefix = 'foo'^M
  sys.base_exec_prefix = 'foo'^M
  sys.platlibdir = 'lib64'^M
  sys.executable = '/usr/bin/python'^M
  sys.prefix = 'foo'^M
  sys.exec_prefix = 'foo'^M
  sys.path = [^M
    'foo/lib64/python39.zip',^M
    'foo/lib64/python3.9',^M
    'foo/lib64/python3.9/lib-dynload',^M
  ]^M
Fatal Python error: init_fs_encoding: failed to get the Python codec of the \
  filesystem encoding^M
Python runtime state: core initialized^M
ModuleNotFoundError: No module named 'encodings'^M
^M
Current thread 0x00007fffabe18480 (most recent call first):^M
<no Python frame>^M
ERROR: (eof) GDB never initialized.
Couldn't send python print (1) to GDB.
UNRESOLVED: gdb.python/py-failed-init.exp: gdb-command<python print (1)>
Couldn't send quit to GDB.
UNRESOLVED: gdb.python/py-failed-init.exp: quit
...

The test-case expects gdb to present a prompt, but instead gdb calls exit
with this back trace:
...
(gdb) bt
 #0  0x00007ffff6e4bfbc in exit () from /lib64/glibc-hwcaps/power10/libc.so.6
 #1  0x00007ffff7873fc4 in fatal_error.lto_priv () from /lib64/libpython3.9.so.1.0
 #2  0x00007ffff78aae60 in Py_ExitStatusException () from /lib64/libpython3.9.so.1.0
 #3  0x00007ffff78c0e58 in Py_InitializeEx () from /lib64/libpython3.9.so.1.0
 #4  0x0000000010b6cab4 in py_initialize_catch_abort () at gdb/python/python.c:2456
 #5  0x0000000010b6cfac in py_initialize () at gdb/python/python.c:2540
 #6  0x0000000010b6d104 in do_start_initialization () at gdb/python/python.c:2595
 #7  0x0000000010b6eaac in gdbpy_initialize (extlang=0x11b7baf0 <extension_language_python>)
     at gdb/python/python.c:2968
 #8  0x000000001069d508 in ext_lang_initialization () at gdb/extension.c:319
 #9  0x00000000108f9280 in captured_main_1 (context=0x7fffffffe870)
     at gdb/main.c:1100
 #10 0x00000000108fa3cc in captured_main (context=0x7fffffffe870)
     at gdb/main.c:1372
 #11 0x00000000108fa4d8 in gdb_main (args=0x7fffffffe870) at gdb/main.c:1401
 #12 0x000000001001d1d8 in main (argc=3, argv=0x7fffffffece8) at gdb/gdb.c:38
...

This may be a python issue [1].

The problem doesn't happen if we use the PyConfig approach instead of the
py_initialize_catch_abort approach.

Fix this by using the PyConfig approach starting 3.9 (previously, starting
3.10 to avoid Py_SetProgramName deprecation in 3.11).

It's possible that we have the same problem and need the same fix for 3.8, but
I don't have a setup to check that.  Add a todo in a comment.

Tested on ppc64le-linux.

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

[1] https://github.com/python/cpython/issues/107827

1 files changed, 15 insertions, 5 deletions

diff --git a/gdb/python/python.c b/gdb/python/python.c
index 51e7a0a..9c30d99 100644
--- a/gdb/python/python.c
+++ b/gdb/python/python.c
@@ -2432,7 +2432,17 @@ gdbpy_gdb_exiting (int exit_code)
     gdbpy_print_stack ();
 }
 
-#if PY_VERSION_HEX < 0x030a0000
+/* Use PyConfig mechanisms for Python 3.9 and newer.
+
+   We used to do this for 3.10 and newer to avoid Py_SetProgramName
+   deprecation in 3.11.
+
+   With 3.9 and the py_initialize_catch_abort approach, we run into a problem
+   where exit is called instead of abort, making gdb exit (possibly
+   https://github.com/python/cpython/issues/107827).  Using the PyConfig
+   mechanism (available starting 3.8) fixes that.  Todo: see if we have the
+   same problem for 3.8, and if we can apply the same fix.  */
+#if PY_VERSION_HEX < 0x03090000
 /* Signal handler to convert a SIGABRT into an exception.  */
 
 static void
@@ -2484,7 +2494,8 @@ py_initialize ()
        ? AUTO_BOOLEAN_TRUE
        : AUTO_BOOLEAN_FALSE);
 
-#if PY_VERSION_HEX < 0x030a0000
+/* Use PyConfig mechanisms for Python 3.9 and newer.  */
+#if PY_VERSION_HEX < 0x03090000
   /* Python documentation indicates that the memory given
      to Py_SetProgramName cannot be freed.  However, it seems that
      at least Python 3.7.4 Py_SetProgramName takes a copy of the
@@ -2525,9 +2536,8 @@ py_initialize ()
   }
 #endif
 
-  /* Py_SetProgramName was deprecated in Python 3.11.  Use PyConfig
-     mechanisms for Python 3.10 and newer.  */
-#if PY_VERSION_HEX < 0x030a0000
+/* Use PyConfig mechanisms for Python 3.9 and newer.  */
+#if PY_VERSION_HEX < 0x03090000
   /* Note that Py_SetProgramName expects the string it is passed to
      remain alive for the duration of the program's execution, so
      it is not freed after this call.  */