[gdb/python] Use PyConfig for python 3.9HEADmaster

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

0 files changed, 0 insertions, 0 deletions