0

I am trying to understand what happens / is supposed to happen when I attach to a process with a debugger in VS Code.

I understand that I can create attach launch configurations in VS Code, and when I do this and start the debug configuration, I can select the process I want to attach to. What is supposed to happen now?

  1. Which prerequisites does the process need to fulfill to be "attachable"? How is this checkend?
  2. What is (conceptionally) going on under the hood?
  3. Which impact does the specific debug configuration have that I use? Does the debugger need to support "attaching"?
  4. Can I expect this to work with basically any debugger and language? What are the prerequisites?
  5. Can I potentially debug shared libraries (.so / .dll) that way?

Answers to parts of the questions are welcome. Not all questions may be applicable.

Motivation

Here, I am seeking a general understanding of what happens under the hood. However, at the end, I would like to see if I can somehow debug Go code that is embedded into a Python package via GoPy.

starball
  • 20,030
  • 7
  • 43
  • 238
Samufi
  • 2,465
  • 3
  • 19
  • 43
  • "_Answers to parts of the questions are welcome._" that's not how Stack Overflow works. And you should avoid asking multiple questions in one question post unless they are very strongly related. I think your question #5 should go in its own follow-up question in a separate question post. – starball Apr 01 '23 at 04:13

1 Answers1

0

Which prerequisites does the process need to fulfill to be "attachable"?

I'm pretty sure it depends on the underlying technology- how the particular debugger service works- what its protocol is, which ends up determining how the extension that communicates with that debugging service works, and translates information about it to VS Code's debugger API. For full info on the topic, see the VS Code Debugger Extension Development docs. Here's a high-level diagram from that page:

And a quote:

VS Code implements a generic (language-agnostic) debugger UI based on an abstract protocol that we've introduced to communicate with debugger backends. Because debuggers typically do not implement this protocol, some intermediary is needed to "adapt" the debugger to the protocol. This intermediary is typically a standalone process that communicates with the debugger.

We call this intermediary the Debug Adapter (or DA for short) and the abstract protocol that is used between the DA and VS Code is the Debug Adapter Protocol (DAP for short). Since the Debug Adapter Protocol is independent from VS Code, it has its own web site where you can find an introduction and overview, the detailed specification, and some lists with known implementations and supporting tools. The history of and motivation behind DAP is explained in this blog post.

If you're interested in learning about the attaching part of things, see https://microsoft.github.io/debug-adapter-protocol/overview#launching-and-attaching, which links to https://microsoft.github.io/debug-adapter-protocol/specification#Requests_Attach, which says:

The attach request is sent from the client to the debug adapter to attach to a debuggee that is already running.

Since attaching is debugger/runtime specific, the arguments for this request are not part of this specification.

at the end, I would like to see if I can somehow debug Go code that is embedded into a Python package via GoPy.

I assume it's not really trivial to implement these things, and they're usually done on a per-technology basis. You could just run two debugger sessions and attach to the inner program. Or you could take a look at what dedicated extensions are doing if you're interested in trying to write a custom extension for your use-case. Ex. benjamin-simmonds.pythoncpp-debug.

starball
  • 20,030
  • 7
  • 43
  • 238