openocd: Remote 'g' packet reply is too long (expected 388 bytes, got 608 bytes) (IDFGH-7851)

[xobs]

Environment

• Development Kit: ESP32-S3-DevKitC-1
• Module or chip used: ESP32S3
• IDF version (run git describe --tags to find it): v5.0-dev-4037-g9b8c558e63
• Build System: CMake
• Compiler version (run xtensa-esp32-elf-gcc --version to find it): xtensa-esp-elf-gdb-3.8 --version: GNU gdb (esp-gdb) 11.2_20220529
• Operating System: Windows
• (Windows only) environment type: PowerShell
• Using an IDE?: Visual Studio Code
• Power Supply: USB

Problem Description

The ESP toolchain was installed by vscode. xtensa-esp32s3-elf-gdb and friends do not run. xtensa-esp-elf-gdb-3.8 runs, but cannot connect to openocd.

[11:42:39 pm] ~/esp/esp-idf> xtensa-esp-elf-gdb-3.8 --version
GNU gdb (esp-gdb) 11.2_20220529
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
[11:43:30 pm] ~/esp/esp-idf> xtensa-esp32s3-elf-gdb --version
[11:43:34 pm] ~/esp/esp-idf> xtensa-esp32-elf-gdb --version
[11:43:37 pm] ~/esp/esp-idf> Get-Command xtensa-esp32-elf-gdb

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Application     xtensa-esp32-elf-gdb.exe                           0.0.0.0    C:\Users\Sean\.espressif\tools\xtensa-esp-elf-gdb\11.2_20220529\xtensa-esp-elf-gdb\bin\xtens…

[11:43:43 pm] ~/esp/esp-idf> Get-Command xtensa-esp-elf-gdb-3.8.exe

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Application     xtensa-esp-elf-gdb-3.8.exe                         0.0.0.0    C:\Users\Sean\.espressif\tools\xtensa-esp-elf-gdb\11.2_20220529\xtensa-esp-elf-gdb\bin\xtens…

[11:43:52 pm] ~/esp/esp-idf>

Expected Behavior

GDB should run, and it should be able to connect to openocd.

Actual Behavior

gdb does not run. When I get gdb to run, it fails.

[11:43:52 pm] ~/esp/esp-idf> xtensa-esp32-elf-gdb --version
[11:45:12 pm] ~/esp/esp-idf> echo $LASTEXITCODE
0
[11:45:14 pm] ~/esp/esp-idf> xtensa-esp32s3-elf-gdb.exe --version
[11:45:24 pm] ~/esp/esp-idf> echo $LASTEXITCODE
0
[11:45:25 pm] ~/esp/esp-idf>xtensa-esp-elf-gdb-3.8 .\build\blackmagic.elf -ex 'tar ext :3333'
GNU gdb (esp-gdb) 11.2_20220529
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-w64-mingw32 --target=xtensa-esp-elf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
.\build\blackmagic.elf: No such file or directory.
Remote debugging using :3333
warning: No executable has been specified and target does not support
determining executable automatically.  Try using the "file" command.
Remote 'g' packet reply is too long (expected 388 bytes, got 608 bytes): 854738407fb73740c071cb3fe071cb3f000000000000000038b73740000000000000000072a237807071cb3fe071cb3f74533840e470ca3f148cca3f000000c00000004049533880e070cb3f4834ca3fa868ca3f5c473840f870cb3f7871cb3f0071cb3ff64b3880b070cb3fa573cb3f148cca3f000000004834ca3f00f001600100000080000000000000604834ca3fb870cb3f01000000b870cb3f00f0016001000000010000002a000000000000600100000008000000b470cb3ff031cf3f00000000ffffffffd040ca3f5491ca3f01000080502fcf3f302fcf3f648eca3fffffffff650300000000000040f9ce3f648eca3f29a83740e071cb3f3a0000007047ca3fc8b13840d2b1384000000000100000000600000055800000854738401f0f092324000600a471c63f00000000ffff3fb3000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
(gdb)

Steps to reproduce

1. Remove ~/.espressif/ and ~/esp/
2. Open vscode
3. Install esp-idf from master

[igrr]

@xobs Thank you for the issue report! Just to check one detail, could you please try running:

xtensa-esp-elf-gdb-3.8 --mcpu=esp32s3 .\build\blackmagic.elf -ex 'tar ext :3333'

and see what the result is?

Looks like there are two issues:

• xtensa-esp32s3-elf-gdb wrapper fails for some reason
• when launching xtensa-esp-elf-gdb*, the CPU type is set to esp32 by default. To choose esp32s3, we should use -mcpu argument. There should probably be a better diagnostic message if we are loading an ELF file built for esp32s3 while using the esp32 target.

[xobs]

@igrr yes, specifying --mcpu=esp32s3 does allow me to attach. You're correct in deducing that the issue was that gdb cannot detect the target device correctly, and is giving a cryptic error.

I feel that the installation process is currently broken. This may be due to an inconsistency in current toolchain versions. I'm seeing the following errors. Where should I report them?

1. gdb wrappers do not work -- they silently fail
2. Out-of-the-box, only xtensa-esp-elf-gdb-no-python works -- all other gdbs silently exit
3. If I run one of the gdbs under WinDbg (X64), I get an error message saying that python3Y.dll is missing
4. I can get xtensa-esp-elf-gdb-3.8.exe to run if I do the following:
5. cp ~\.espressif\tools\idf-python\3.8.7\python38.dll ~\.espressif\tools\xtensa-esp-elf-gdb\11.2_20220529\xtensa-esp-elf-gdb\bin\
6. cp -Recurse ~\.espressif\tools\idf-python\3.8.7\Lib ~\.espressif\tools\xtensa-esp-elf-gdb\11.2_20220529\xtensa-esp-elf-gdb\bin\

So it seems like the compilers are assuming there's a python distribution alongside them, but that python runtime is not getting shipped.

Additionally, if I remove ~.espressif and ~\esp and re-run the vscode installer, then idf complains the incorrect toolchain was installed:

[8:52:58 am] ~> rm -Recurse -Force .\.espressif
[8:53:12 am] ~> rm -Recurse -Force .\esp
[8:53:12 am] ~> exit

install esp-idf master branch via vscode

PowerShell 7.2.5
Copyright (c) Microsoft Corporation.

https://aka.ms/powershell
Type 'help' to get help.

[8:59:16 am] ~> cd .\esp\esp-idf\
[8:59:20 am] ~/esp/esp-idf> .\export.ps1
Setting IDF_PATH: C:\Users\Sean\esp\esp-idf
Checking Python compatibility
Adding ESP-IDF tools to PATH...

Name                           Value
----                           -----
OPENOCD_SCRIPTS                C:\Users\Sean\.espressif\tools\openocd-esp32\v0.11.0-esp32-20220411\openocd-esp32\share\openocd\scripts
IDF_CCACHE_ENABLE              1
ESP_IDF_VERSION                5.0

Added to PATH
-------------
C:\Users\Sean\esp\esp-idf\components\esptool_py\esptool
C:\Users\Sean\esp\esp-idf\components\app_update
C:\Users\Sean\esp\esp-idf\components\espcoredump
C:\Users\Sean\esp\esp-idf\components\partition_table
C:\Users\Sean\.espressif\tools\xtensa-esp-elf-gdb\11.2_20220529\xtensa-esp-elf-gdb\bin
C:\Users\Sean\.espressif\tools\riscv32-esp-elf-gdb\11.2_20220529\riscv32-esp-elf-gdb\bin
C:\Users\Sean\.espressif\tools\xtensa-esp32-elf\esp-2022r1-RC1-11.2.0\xtensa-esp32-elf\bin
C:\Users\Sean\.espressif\tools\xtensa-esp32s2-elf\esp-2022r1-RC1-11.2.0\xtensa-esp32s2-elf\bin
C:\Users\Sean\.espressif\tools\xtensa-esp32s3-elf\esp-2022r1-RC1-11.2.0\xtensa-esp32s3-elf\bin
C:\Users\Sean\.espressif\tools\riscv32-esp-elf\esp-2022r1-RC1-11.2.0\riscv32-esp-elf\bin
C:\Users\Sean\.espressif\tools\esp32ulp-elf\2.28.51-esp-20191205\esp32ulp-elf-binutils\bin
C:\Users\Sean\.espressif\tools\esp32s2ulp-elf\2.28.51-esp-20191205\esp32s2ulp-elf-binutils\bin
C:\Users\Sean\.espressif\tools\cmake\3.23.1\bin
C:\Users\Sean\.espressif\tools\openocd-esp32\v0.11.0-esp32-20220411\openocd-esp32\bin
C:\Users\Sean\.espressif\tools\idf-exe\1.0.3\
C:\Users\Sean\.espressif\tools\ccache\4.3\ccache-4.3-windows-64
C:\Users\Sean\.espressif\tools\dfu-util\0.9\dfu-util-0.9-win64
C:\Users\Sean\esp\esp-idf\tools
Checking if Python packages are up to date...
ERROR: C:\Users\Sean\.espressif\python_env\idf5.0_py3.10_env\Scripts\python.exe doesn't exist! Please run the install script or "idf_tools.py install-python-env" in order to create it

Detected installed tools that are not currently used by active ESP-IDF version.
For removing dfu-util, esp32s2ulp-elf, esp32ulp-elf, riscv32-esp-elf, riscv32-esp-elf-gdb, xtensa-esp-elf-gdb, xtensa-esp32-elf, xtensa-esp32s2-elf, xtensa-esp32s3-elf use command 'python.exe C:\Users\Sean\esp\esp-idf\tools\idf_tools.py uninstall'
For free up even more space, remove installation packages of those tools. Use option 'python.exe C:\Users\Sean\esp\esp-idf\tools\idf_tools.py uninstall --remove-archives'.


Done! You can now compile ESP-IDF projects.
Go to the project directory and run:
    idf.py build



[8:59:28 am] ~/esp/esp-idf> xtensa-esp-elf-gdb-no-python.exe --version
GNU gdb (esp-gdb) 11.2_20220529
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
[9:00:07 am] ~/esp/esp-idf> python.exe C:\Users\Sean\esp\esp-idf\tools\idf_tools.py uninstall
C:\Users\Sean\.espressif\tools\dfu-util was removed.
C:\Users\Sean\.espressif\tools\esp32s2ulp-elf was removed.
C:\Users\Sean\.espressif\tools\esp32ulp-elf was removed.
C:\Users\Sean\.espressif\tools\riscv32-esp-elf was removed.
C:\Users\Sean\.espressif\tools\riscv32-esp-elf-gdb was removed.
C:\Users\Sean\.espressif\tools\xtensa-esp-elf-gdb was removed.
C:\Users\Sean\.espressif\tools\xtensa-esp32-elf was removed.
C:\Users\Sean\.espressif\tools\xtensa-esp32s2-elf was removed.
C:\Users\Sean\.espressif\tools\xtensa-esp32s3-elf was removed.
[9:00:11 am] ~/esp/esp-idf> xtensa-esp-elf-gdb-no-python.exe --version
xtensa-esp-elf-gdb-no-python.exe: The term 'xtensa-esp-elf-gdb-no-python.exe' is not recognized as a name of a cmdlet, function, script file, or executable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
[9:00:13 am] ~/esp/esp-idf>

I can then run python.exe C:\Users\Sean\esp\esp-idf\tools\idf_tools.py install to reinstall it.

So something is definitely going wrong with the toolchain if vscode installs it, and the python libraries are definitely getting omitted by the default installer.

[igrr]

I think the issue with gdb not picking up installed Python libraries will be fixed in the new GDB release, https://github.com/espressif/binutils-gdb/releases/tag/esp-gdb-v11.2_20220529. We have just merged the commit to internal IDF branch where we update GDB to that release. We will let you know once that change gets deployed to Github, so that you can test that.

Regarding the second issue (about VS Code), could you please report it to https://github.com/espressif/vscode-esp-idf-extension/issues?

[igrr]

@xobs GDB release used in IDF master branch has been updated in c0e94c6, could you please give it a try?

[xobs]

I can confirm that I'm using that version of GDB, however it does not solve the underlying issue.

I removed ~/esp as well as ~/.espressif and re-ran setup using the vscode extension. The resulting setup behaved exactly the same way:

esp-idf on  master via 喝 v3.23.1 via  v3.10.5 took 8s
❯ xtensa-esp32s3-elf-gdb.exe

esp-idf on  master via 喝 v3.23.1 via  v3.10.5
❯ xtensa-esp-elf-gdb-3.10.exe

esp-idf on  master via 喝 v3.23.1 via  v3.10.5
❯ xtensa-esp-elf-gdb-no-python.exe --version
GNU gdb (esp-gdb) 11.2_20220715
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

esp-idf on  master via 喝 v3.23.1 via  v3.10.5
❯ get-command xtensa-esp-elf-gdb-no-python.exe

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Application     xtensa-esp-elf-gdb-no-python.exe                   0.0.0.0    C:\Users\smcro\.espressif\tools\xtensa-e…


esp-idf on  master via 喝 v3.23.1 via  v3.10.5
❯

[Lapshin]

Sorry for the long delay, @xobs

I can not reproduce the issue. The way I do it:

• Fresh Windows 10 installation
• Install Python 3.10.5 from https://www.python.org/downloads/release/python-3105/
• Install the latest VSCode (I don't think it is the required step)
• git clone esp-idf
• in VSCode terminal
  • .\install.ps1
  • .\export.ps1

after that I was able to run xtensa GDBs without any issue.

But I found that if I install 32-bit Python on my 64-bit Windows I have the same behavior as you described.

Could you please run a few commands in PowerShell:

wmic os get osarchitecture
python -c "import platform; print(platform.architecture())"
python.exe -c "import sysconfig; import sys; import os; print(sysconfig.get_config_vars()); print(os.listdir(sys.base_prefix))
$env:ESP_DEBUG_TRACE=1; xtensa-esp32s3-elf-gdb

[xobs]

Sure, here you go:

PS E:\Code\Farpatch\farpatch> wmic os get osarchitecture
OSArchitecture  
64-bit

PS E:\Code\Farpatch\farpatch> python -c "import platfrm; print(platform.architecture())"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ModuleNotFoundError: No module named 'platfrm'
PS E:\Code\Farpatch\farpatch> python.exe -c "import sysconfig; import sys; import os; print(sysconfig.get_config_vars()); print(os.listdir(sys.base_prefix))"
{'prefix': 'C:\\Users\\Sean\\.espressif\\python_env\\idf5.0_py3.10_env', 'exec_prefix': 'C:\\Users\\Sean\\.espressif\\python_env\\idf5.0_py3.10_env', 'py_version': '3.10.5', 'py_version_short': '3.10', 'py_version_nodot': '310', 'installed_base': 'C:\\Program Files\\WindowsApps\\PythonSoftwareFoundation.Python.3.10_3.10.1520.0_x64__qbz5n2kfra8p0', 'base': 'C:\\Users\\Sean\\.espressif\\python_env\\idf5.0_py3.10_env', 'installed_platbase': 'C:\\Program Files\\WindowsApps\\PythonSoftwareFoundation.Python.3.10_3.10.1520.0_x64__qbz5n2kfra8p0', 'platbase': 'C:\\Users\\Sean\\.espressif\\python_env\\idf5.0_py3.10_env', 'projectbase': 'C:\\Users\\Sean\\.espressif\\python_env\\idf5.0_py3.10_env\\Scripts', 'platlibdir': 'lib', 'abiflags': '', 'py_version_nodot_plat': '310', 'LIBDEST': 'C:\\Program Files\\WindowsApps\\PythonSoftwareFoundation.Python.3.10_3.10.1520.0_x64__qbz5n2kfra8p0\\Lib', 'BINLIBDEST': 'C:\\Users\\Sean\\.espressif\\python_env\\idf5.0_py3.10_env\\Lib', 'INCLUDEPY': 'C:\\Program Files\\WindowsApps\\PythonSoftwareFoundation.Python.3.10_3.10.1520.0_x64__qbz5n2kfra8p0\\Include', 'EXT_SUFFIX': '.cp310-win_amd64.pyd', 'EXE': '.exe', 'VERSION': '310', 'BINDIR': 'C:\\Users\\Sean\\.espressif\\python_env\\idf5.0_py3.10_env\\Scripts', 'TZPATH': '', 'SO': '.cp310-win_amd64.pyd', 'userbase': 'C:\\Users\\Sean\\AppData\\Local\\Packages\\PythonSoftwareFoundation.Python.3.10_qbz5n2kfra8p0\\LocalCache\\local-packages', 'srcdir': 'C:\\Users\\Sean\\.espressif\\python_env\\idf5.0_py3.10_env\\Scripts'}   
['AppxBlockMap.xml', 'AppxManifest.xml', 'AppxMetadata', 'AppxSignature.p7x', 'classicAppCompat.sccd', 'DLLs', 'idle3.10.exe', 'include', 'Lib', 'libs', 'LICENSE.txt', 'microsoft.system.package.metadata', 'pip.ini', 'pip3.10.exe', 'python.exe', 'python3.10.exe', 'python3.dll', 'python310.dll', 'pythonw.exe', 'pythonw3.10.exe', 'resources.pri', 'tcl', 'vcruntime140.dll', 'vcruntime140_1.dll', '_resources']
PS E:\Code\Farpatch\farpatch> $env:ESP_DEBUG_TRACE=1; xtensa-esp32s3-elf-gdb
Found python version: 3.10
Run with python-3.10
PS E:\Code\Farpatch\farpatch> 

Normally I use Powershell, and not VSCode, but I get the same behaviour when I run it in straight powershell.

I'm seeing this on both of my Windows machines, so I'm unsure if it's some cruft leftover on this machine.

[Lapshin]

@xobs ,

Could you rerun

python -c "import platform; print(platform.architecture())"

it has a typo in your output

[xobs]

Sure, my mistake for not noticing that. I guess there was an error in buffering when I pasted the commands into vscode.

In any case:

PS E:\Code\Farpatch\farpatch> python -c "import platform; print(platform.architecture())"
('64bit', 'WindowsPE')
PS E:\Code\Farpatch\farpatch> 

I get the same output when I run it from powershell:

[11:32:05 pm] E:/Code/Farpatch/farpatch> python -c "import platform; print(platform.architecture())"
('64bit', 'WindowsPE')
[9:23:58 am] E:/Code/Farpatch/farpatch>

[xobs]

I can verify that 20220729 has fixed this issue:

[4:03:49 pm] ~/esp/esp-idf> xtensa-esp32s3-elf-gdb.exe
GNU gdb (esp-gdb) 11.2_20220729
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-w64-mingw32 --target=xtensa-esp-elf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb)

Thanks for the fix!