Created attachment 9056 [details]
gdb-pretty-printers-import-script-workaround.patch

gcc-10.3.0
libstdc++ 6.0.28
python 3.9
gdb 10.3

How to reproduce:

 - build firmware with:
   
     BR2_GCC_VERSION_10_X=y
     BR2_GCC_VERSION="10.3.0"
     BR2_TOOLCHAIN_BUILDROOT_CXX=y
   
     BR2_PACKAGE_HOST_GDB=y
     BR2_PACKAGE_HOST_GDB_TUI=y
     BR2_PACKAGE_HOST_GDB_PYTHON3=y
     BR2_GDB_VERSION_10=y
     BR2_GDB_VERSION="10.1"

     BR2_PACKAGE_GDB_ARCH_SUPPORTS=y
     BR2_PACKAGE_GDB=y
     BR2_PACKAGE_GDB_SERVER=y
   
     BR2_PACKAGE_HOST_PYTHON3=y

  - cross compile c++ application with debug symbols.

  - remotely debug application on the target.

  - print the value of an stl object.

Expected:

  A human readable value.

Actually:

  Dumps the implementation details of the stl objects.

  gdb also prints this error:

    Traceback (most recent call last):
    File "/opt/heliox/some-board-sdk/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libstdc++.so.6.0.28-gdb.py", line 61, in <module>
    from libstdcxx.v6 import register_libstdcxx_printers
        ModuleNotFoundError: No module named 'libstdcxx'


Root cause:

The script that fails is the python import script. It is supplied by gcc/libstdc++ and is generated from this template:
https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/python/hook.in

The script is supposed to set the path to the libstdcxx python module, import it and register the printers with gdb.
It has the correct info to do so, however it manages to mess it up in my case.

The script contains two hard-coded paths:

    pythondir = '/opt/heliox/some-board-sdk/share/gcc-10.3.0/python/'
    libdir = '/opt/heliox/some-board-sdk/arm-buildroot-linux-gnueabihf/lib'

The pythondir is the exact path needed for the import. Replacing the whole script with just:

    sys.path.insert(0, '/opt/heliox/some-board-sdk/share/gcc-10.3.0/python/')
    from libstdcxx.v6 import register_libstdcxx_printers
    register_libstdcxx_printers(gdb.current_objfile())

Fixes my problem.

The error occurs when the script tries to construct a relative path from libdir to pythondir and append that to the directory of the object file being debugged (/opt/heliox/some-board-sdk/arm-buildroot-linux-gnueabihf/sysroot/lib/libstdc++.so.6)

This results in a non existent path:

    /opt/heliox/some-board-sdk/arm-buildroot-linux-gnueabihf/sysroot/lib/../../share/gcc-10.3.0/python

I don't know enough python to understand why a new path needs to be constructed, however it seems to me that the path calculation is wrong;
it should calculate the relative path from object dir to pythondir and append that to the object dir.

For now I added a patch with a workaround (see attached file).

Kind regards,
Dennis Peeten.