pico_project.py generates wrong lunch.json for Linux

[mr-kycho]

There are two issues when generating lunch.json for Linux in the pico_project.py script:

• gdbPath is set to gdb, but it should be gdb-multiarch: "gdbPath": "gdb-multiarch"
• servertype is set to path/openocd.exe, but is should be: "servertype": "openocd"

[paulober]

Servertype is hardcoded:

pico-vscode/scripts/pico_project.py

Line 767 in 6e3f33c

"servertype": "openocd",\

pico-vscode/scripts/pico_project.py

Line 792 in 6e3f33c

"servertype": "external",

Did you mean why serverpath is openocd.exe on linux? Thats on purpose, openocd.exe on linux is a symlink to the openocd binary.

But setting gdb on linux to gdb-multiarch may be a good solution as it would support arm on every host but would add a new requirement. What do you mean @will-v-pi?

[mr-kycho]

Ok, to be more specific, the gdbPath set to gdb doesn't work on Linux for the x86-64 architecture, however on Linux for ARM it works I guess, and there is no need to install gdb-multiarch.
Personally, it is weird to see an EXE file in the configuration file on Linux.

[ncicek]

Thanks, I was scratching my head wondering why gdb wouldn't connect from my x86 laptop.
Installing gdb-multiarch and updating the launch.json file fixed it.

I agree, this should be addressed in order to be usable from any non-ARM system.
With default gdb on x86, we get errors like:

• Truncated register 16 in remote 'g' packet
• Target description specified unknown architecture "arm"

[will-v-pi]

But setting gdb on linux to gdb-multiarch may be a good solution as it would support arm on every host but would add a new requirement. What do you mean @will-v-pi?

The current reason for using just gdb on Linux is to support Raspberry Pi OS, which doesn't have the required libraries to work with the Arm provided gdb.

If that's not working on non-Arm Linux distros, then I think the first solution to look at would be to see if the Arm toolchain GDB works on those distros and use that on non-Arm Linux distros, like we do on MacOS and Windows (sticking with gdb for Raspberry Pi OS)

@mr-kycho or @ncicek could you try out using the Arm provided gdb (the extension puts it at ~/.pico-sdk/toolchain/13_2_Rel1/bin/arm-none-eabi-gdb if you have the default version) in launch.json and see if that works on your systems? If it does then that's the easiest solution, so we don't introduce a requirement on gdb-multiarch

[ncicek]

I put "gdbPath": "~/.pico-sdk/toolchain/13_2_Rel1/bin/arm-none-eabi-gdb" and got the following error:

Error: ~/.pico-sdk/toolchain/13_2_Rel1/bin/arm-none-eabi-nm failed! statics/global/functions may not be properly classified: Error: spawn ~/.pico-sdk/toolchain/13_2_Rel1/bin/arm-none-eabi-nm ENOENT Expecting `nm` next to `objdump`. If that is not the problem please report this. Could not start GDB process, does the program exist in filesystem? Error: spawn ~/.pico-sdk/toolchain/13_2_Rel1/bin/arm-none-eabi-gdb ENOENT

[will-v-pi]

Can you double check ~/.pico-sdk/toolchain/13_2_Rel1/bin/arm-none-eabi-gdb exists - if you installed a different toolchain version it may be under that instead (eg ~/.pico-sdk/toolchain/12_3_Rel1/bin/arm-none-eabi-gdb)? Also, try using ${userHome} instead of ~ if it still doesn't work

[ncicek]

${userHome} made the difference.
I set "${userHome}/.pico-sdk/toolchain/13_2_Rel1/bin/arm-none-eabi-gdb", but it was looking for python3.8. Basically this: https://stackoverflow.com/questions/72187185/arm-none-eabi-gdb-cannot-start-because-of-some-python-error

After installing python3.8 from AUR on my system it worked.

I'm not familiar with vscode packaging, but is there a way to include the python3.8 dependency within this package?

[ncicek]

My system python is 3.12. This is the error I got before installing python3.8:

Could not find platform independent libraries
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to [:<exec_prefix>]
Python path configuration:
PYTHONHOME = (not set)
PYTHONPATH = (not set)
program name = '/usr/local/bld-tools/bld-tools-virtual-env/bin/python'
isolated = 0
environment = 1
user site = 1
import site = 1
sys._base_executable = '/usr/local/bld-tools/bld-tools-virtual-env/bin/python'
sys.base_prefix = '/usr'
sys.base_exec_prefix = '/usr'
sys.executable = '/usr/local/bld-tools/bld-tools-virtual-env/bin/python'
sys.prefix = '/usr'
sys.exec_prefix = '/usr'
sys.path = [
'/usr/lib/python38.zip',
'/usr/lib/python3.8',
'/usr/lib/lib-dynload',
]
Fatal Python error: init_fs_encoding: failed to get the Python codec of the filesystem encoding
Python runtime state: core initialized
ModuleNotFoundError: No module named 'encodings'