I don't see a description of how to reproduce this, so I googled the error message and suse and found https://stackoverflow.com/questions/71104698/no-module-named-encodings-on-opensuse, which suggest that this can happen when PYTHONHOME is set.

So, tentative description of the problem: gdb is used with PYTHONHOME which is incompatible (or possibly, incorrect), and aborts.

It's possible the problem is fixed by using gdb -eiex "set python ignore-environment on" or adding that setting to one of gdb's early initialization files ( https://sourceware.org/gdb/current/onlinedocs/gdb.html/Initialization-Files.html ).

If so, this is at least partly a duplicate of PR22503.

It would be better if gdb didn't abort.

(In reply to Tom de Vries from comment #1)
> It would be better if gdb didn't abort.

OK, actually it's python that aborts, as per spec of Py_Initialize.  Starting python version 3.10, gdb instead calls Py_InitializeFromConfig() which doesn't abort.

https://sourceware.org/pipermail/gdb-patches/2024-November/213438.html

(In reply to Tom de Vries from comment #1)
> It's possible the problem is fixed by using gdb -eiex "set python
> ignore-environment on" or adding that setting to one of gdb's early
> initialization files (
> https://sourceware.org/gdb/current/onlinedocs/gdb.html/Initialization-Files.
> html ).

I've proposed a warning to advertise this option ( https://sourceware.org/pipermail/gdb-patches/2024-November/213485.html ).

The master branch has been updated by Tom de Vries <vries@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=9d3785a8ac15dcc369b8c0b1074c5ca7145cdda7

commit 9d3785a8ac15dcc369b8c0b1074c5ca7145cdda7
Author: Tom de Vries <tdevries@suse.de>
Date:   Fri Nov 22 19:34:24 2024 +0100

    [gdb/python] Fix abort on Py_Initialize
    
    I tried out making python initialization fail by passing an incorrect
    PYTHONHOME with python 3.6, and got:
    ...
    $ PYTHONHOME=foo gdb -q
    Fatal Python error: Py_Initialize: Unable to get the locale encoding
    ModuleNotFoundError: No module named 'encodings'
    
    Current thread 0x0000ffff89269c80 (most recent call first):
    
    Fatal signal: Aborted
      ...
    Aborted (core dumped)
    $
    ...
    
    This is as per spec: when Py_Initialize () fails, a fatal error is raised
    using Py_FatalError.
    
    This can be worked around using:
    ...
    $ PYTHONHOME=foo gdb -q -eiex "set python ignore-environment on"
    (gdb)
    ...
    but it would be better if gdb didn't abort.
    
    I found an article [1] describing two solutions:
    - try out Py_Initialize in a separate process, and
    - catch the abort using a signal handler.
    
    This patch implements the latter solution.
    
    Obviously we cannot call into python anymore after the abort, so we avoid
    calling Py_IsInitialized (), and instead use a new variable py_isinitialized.
    
    This gets us instead:
    ...
    $ PYTHONHOME=foo gdb -q
    Fatal Python error: Py_Initialize: Unable to get the locale encoding
    ModuleNotFoundError: No module named 'encodings'
    
    Current thread 0x0000fffecfd49c80 (most recent call first):
    Python not initialized
    $
    ...
    
    Tested on aarch64-linux.
    
    Approved-By: Tom Tromey <tom@tromey.com>
    
    PR python/32379
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32379
    
    [1] https://stackoverflow.com/questions/7688374/how-to-i-catch-and-handle-a-fatal-error-when-py-initialize-fails

The master branch has been updated by Tom de Vries <vries@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=6a02aa77d80e4040bea699a88cf0dd208df639b4

commit 6a02aa77d80e4040bea699a88cf0dd208df639b4
Author: Tom de Vries <tdevries@suse.de>
Date:   Tue Dec 3 22:58:47 2024 +0100

    [gdb/python] Issue warning if python fails to initialize
    
    A common problem is that python may fail to initialize if PYTHONHOME is
    set incorrectly, or points to incompatible default libraries.
    
    Likewise if PYTHONPATH points to incompatible modules.
    
    For instance, say PYTHONHOME is foo, then we get:
    ...
    $ gdb -q
    Python path configuration:
      PYTHONHOME = 'foo'
      PYTHONPATH = (not set)
      program name = '/usr/bin/python'
      isolated = 0
      environment = 1
      user site = 1
      safe_path = 0
      import site = 1
      is in build tree = 0
      stdlib dir = 'foo/lib64/python3.12'
      sys._base_executable = '/usr/bin/python'
      sys.base_prefix = 'foo'
      sys.base_exec_prefix = 'foo'
      sys.platlibdir = 'lib64'
      sys.executable = '/usr/bin/python'
      sys.prefix = 'foo'
      sys.exec_prefix = 'foo'
      sys.path = [
        'foo/lib64/python312.zip',
        'foo/lib64/python3.12',
        'foo/lib64/python3.12/lib-dynload',
      ]
    Python Exception <class 'ModuleNotFoundError'>: No module named 'encodings'
    Python not initialized
    $
    ...
    
    In this case, it might be easy to figure out what went wrong because of the
    obviously incorrect pathnames, but that might not be the case if PYTHONHOME
    points to an incompatible python installation.
    
    Fix this by adding a warning with a description of the possible cause and what
    to do about it:
    ...
    Python initialization failed: \
      failed to get the Python codec of the filesystem encoding
    gdb: warning: Python failed to initialize with PYTHONHOME set.  Maybe because \
      it is set incorrectly? Maybe because it points to incompatible standard \
      libraries? Consider changing or unsetting it, or ignoring it using "set \
      python ignore-environment on" at early initialization.
    ...
    
    Likewise for PYTHONPATH:
    ...
    Python initialization failed: \
      failed to get the Python codec of the filesystem encoding
    gdb: warning: Python failed to initialize with PYTHONPATH set.  Maybe because \
      it points to incompatible modules? Consider changing or unsetting it, or \
      ignoring it using "set python ignore-environment on" at early \
      initialization.
    ...
    
    Tested on aarch64-linux.
    
    Approved-By: Tom Tromey <tom@tromey.com>
    
    PR python/32379
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32379

Fixed.