Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Launch gdbtarget fails at the workspace level (VSC-1552) #1394

Open
1 task done
i400s opened this issue Jan 4, 2025 · 1 comment · May be fixed by #1397
Open
1 task done

Launch gdbtarget fails at the workspace level (VSC-1552) #1394

i400s opened this issue Jan 4, 2025 · 1 comment · May be fixed by #1397
Assignees
Labels
bug-report Bug Report from users on Github (don't use this tag manually, its supposed to be used via the issue)

Comments

@i400s
Copy link

i400s commented Jan 4, 2025

OS

Windows

Operating System version

Debian Trixie

Visual Studio Code version

1.96.2

ESP-IDF version

v5.5-dev-1050-gb5ac4fbdf9

Python version

3.12.8

Doctor command output

report.txt

Extension

{"message":"${workspaceFolder}/build/project_description.json doesn't exist.","stack":"Error: ${workspaceFolder}/build/project_description.json doesn't exist.\n\tat /dist/extension.js:2:1418922\n\tat new Promise ()\n\tat fe (/dist/extension.js:2:1418878)\n\tat jc.resolveDebugConfiguration (/dist/extension.js:2:1748101)\n\tat file:///out/vs/workbench/api/node/extensionHostProcess.js:122:99660","level":"error","timestamp":"2025-01-04T11:32:08.582Z"}

Description

When a debug gdbtarget launch configuration is set at the workspace level .code-workspace it fails to run with no errors or messages shown.

Having a launch.json file in multiple application directories causes them to all be displayed within the debug dropdown. This seems fine as they all launch. Having a global launch for the workspace (that should run using the ESP-IDF Current project) only seems to work with "type": "espidf" and not with the "type": "gdbtarget".

To make sure the issue wasn't the multi folder/project workspace that I normally use I created clean environment and a new workspace based on the blink example. I then added a .code-workspace file that pointed to . only.

{
	"folders": [
		{
			"path": "."
		}
	],
	"settings": {
		"idf.port": "/dev/ttyACM1",
		"idf.flashType": "UART",
		"idf.openOcdDebugLevel": 2,
		"idf.openOcdLaunchArgs": [
			"-c adapter serial 40:4C:CA:43:1C:AC"
		],
		"idf.openOcdConfigs": [
			"board/esp32c6-builtin.cfg"
		],
	},
	"launch": {
		"version": "0.2.0",
		"configurations": [
			{
			  "type": "gdbtarget",
			  "request": "attach",
			  "name": "Eclipse CDT GDB Adapter"
			},
			{
			  "type": "espidf",
			  "name": "Launch",
			  "request": "launch"
			}
		],
	},
}

This failed to launch the workspace version of gdbtarget while being able to launch the espidf version at the workstation level and also able to launch the folder level of both gdbtarget and espidf.

Thanks in advance.

Debug Message

none

Other Steps to Reproduce

No response

I have checked existing issues, online documentation and the Troubleshooting Guide

  • I confirm I have checked existing issues, online documentation and Troubleshooting guide.
@i400s i400s added the bug-report Bug Report from users on Github (don't use this tag manually, its supposed to be used via the issue) label Jan 4, 2025
@github-actions github-actions bot changed the title Launch gdbtarget fails at the workspace level Launch gdbtarget fails at the workspace level (VSC-1552) Jan 4, 2025
@brianignacio5
Copy link
Collaborator

The issue here it seems that launch configurations defined in .code-workspace doesn't define which folder to use for debugging when launching the debug session.

The question is then, how to identify which folder to use for debug in this case? We have a ESP-IDF: Pick a Workspace Folder command to select the current workspace folder to use which is used in espidf configuration but we could also make it available here.

@brianignacio5 brianignacio5 linked a pull request Jan 7, 2025 that will close this issue
5 tasks
@brianignacio5 brianignacio5 self-assigned this Jan 8, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug-report Bug Report from users on Github (don't use this tag manually, its supposed to be used via the issue)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants