Hi @valeros,
thank you for the input, we had a closer look at the issue. Please see the result of our investigation:
Prerequisites:
Compiler Toolchain: We use the Embedded Workbench for Arm from IAR Systems, version 8.50.9.
Debug Server: The GDB server is provided by an OpenOCD server, configured for Infineon PSoC4 derivatives.
Debug Client and GDB Toolchain: We want to use the GDB client from the arm-none-eabi toolchain, as well as all other necessary tools, to debug in VS Code with the PlatformIO extension.
Problem:
Debugging cannot be started with the error message that the “objdump” program cannot be found. By adding a program to the folder where the binaries of the compiler toolchain are located, debugging can be started. However, the name of a program in this folder must contain the string “objdump”. Setting and hitting breakpoints is now possible, but symbols are either not resolved at all or not displayed correctly in the debug view. Additionally, the code cannot be displayed in “Assembly”.
Cause:
In the .vscode folder, there is a “launch.json” which contains information about certain debug configurations. The parameter “toolchainBinDir” provides the ability to specify a path where programs needed for debugging are generally located. This “launch.json” is generated by the PlatformIO Core. The basis for the generation is a “launch.json.tpl”, in which the “toolchainBinDir” parameter is set. Here, there is a significant difference between PlatformIO Core version 6.1.9 and newer versions like 6.1.18. In version 6.1.18, the variable “cc_path” is found in line 19 of the mentioned file. In version 6.1.9, the variable “gdb_path” is found in line 20. The paths behind these two variables can be easily seen in the Core in builder\tools\piointegration.py, where both variables, “cc_path” and “gdb_path”, are assigned values in both version 6.1.9 and version 6.1.18. As can already be guessed, “cc_path” is assigned the path to the folder where the C compiler is located, specifically the path where the program set for the global “CC” variable is located. The same applies to the “gdb_path” variable, except that here the path to the folder where the GDB client is located, or the program set for the global “GDB” variable, is used.
Solution:
Since in reality the tools needed for compiling/linking and debugging software are not always located in the same directory, an option to manually configure paths would be very helpful. - The simplest solution would certainly be to extract the path of the GDB client again, as in version 6.1.9, and use it as the default directory for the debug tools. - To achieve even more flexibility, it would be good to define some options in the form of additional variables in the Core, where the user has the ability to override the default value. For example, one could create a variable for the “toolchainBinDir” parameter, which can be overridden in the env.Replace() function if needed.
Please let me know if we are on the right path here or more input is needed.
