Allow setting breakpoints whose location is not found yet but will be found in child process

Oct 13, 2025 by pynkocean.com 119 views

Introduction

As a developer working with Go, debugging child processes can be a challenging task. While most Go projects are organized as packages and support single-process debugging with multiple goroutines, there are scenarios where debugging child processes is essential. In this article, we will explore the need for adding support for target exec -on to debug child processes in Go.

Problem Demo

To demonstrate the problem, we can refer to the demo repository Lslightly/delve-dbg-child-proc, where we can debug child processes in Delve. However, debugging child processes in VSCode-Go is not currently supported. This limitation is a significant obstacle for developers working on projects like golang/go, where the cmd/go can invoke cmd/compile tool as a child process.

Related Issues and Blogs

Several issues and blogs have discussed the need for multiple process debugging in Go:

Describe the Solution You'd Like

To address the need for debugging child processes, we propose the following solution:

Enable target follow-exec -on by default or provide an option to enable child process debug: This feature should be enabled by default or provide an option to enable child process debug. The --init option of Delve should be disabled when combining with the --headless option.
Allow setting breakpoints whose location is not found yet but will be found in child process: This feature requires support in Delve to answer "yes" when the breakpoint is not found, setting a suspended breakpoint (in Delve but not in VSCode-Go). The source code location of the yesno decision is pkg/terminal/command.go#L1868.
Reuse the Call Stack for debugging child process: This feature is of low priority, as attach remote and substitutePath (which we have not yet succeeded in using) can be used to debug child processes in different VSCode windows.

Describe Alternatives You've Considered

While the proposed solution addresses the need for debugging child processes, we have considered alternative solutions:

Using attach remote and substitutePath: These features can be used to debug child processes in different VSCode windows, but they are not as straightforward as reusing the Call Stack.
Implementing a custom debugger: A custom debugger could be implemented to support debugging child processes, but this would require significant development effort and may not be compatible with existing debugging tools.

Additional Context

To further illustrate the need for debugging child processes, we will upload a demo video later. This video will demonstrate the challenges of debugging child processes in VSCode-Go and highlight the benefits of adding support for target exec -on.

Conclusion

Q: What is the current limitation in debugging child processes in VSCode-Go?

A: Currently, VSCode-Go does not support debugging child processes. While most Go projects are organized as packages and support single-process debugging with multiple goroutines, there are scenarios where debugging child processes is essential. The demo repository Lslightly/delve-dbg-child-proc demonstrates the problem, where we can debug child processes in Delve but not in VSCode-Go.

Q: Why is debugging child processes important?

A: Debugging child processes is essential for projects like golang/go, where the cmd/go can invoke cmd/compile tool as a child process. The command arguments passed to cmd/compile tool are complicated, making it challenging to debug child processes. Additionally, this scenario is different from the client/server architecture, where the process runs for a long time, and you can connect to the Delve server at any time.

Q: What is the proposed solution to add support for target exec -on to debug child processes?

A: The proposed solution includes:

Enable target follow-exec -on by default or provide an option to enable child process debug: This feature should be enabled by default or provide an option to enable child process debug. The --init option of Delve should be disabled when combining with the --headless option.
Allow setting breakpoints whose location is not found yet but will be found in child process: This feature requires support in Delve to answer "yes" when the breakpoint is not found, setting a suspended breakpoint (in Delve but not in VSCode-Go). The source code location of the yesno decision is pkg/terminal/command.go#L1868.
Reuse the Call Stack for debugging child process: This feature is of low priority, as attach remote and substitutePath (which we have not yet succeeded in using) can be used to debug child processes in different VSCode windows.

Q: What are the alternatives to the proposed solution?

A: While the proposed solution addresses the need for debugging child processes, we have considered alternative solutions:

Using attach remote and substitutePath: These features can be used to debug child processes in different VSCode windows, but they are not as straightforward as reusing the Call Stack.
Implementing a custom debugger: A custom debugger could be implemented to support debugging child processes, but this would require significant development effort and may not be compatible with existing debugging tools.

Q: What is the current status of the proposed solution?

A: The proposed solution is still in the discussion phase. We are seeking feedback and input from the community to refine the solution and ensure it meets the needs of Go developers.

Q: How can I contribute to the proposed solution?

A: We welcome contributions from the community. If you are interested in contributing to the proposed solution, please reach out to us through the GitHub issue tracker or by commenting on this article. We will provide more information on how to contribute and get involved in the development process.