Multi core debugging

Multi-core debugging

WORK IN PROGRESS -- We are currently updating VSCode to add better multi-core debugging which includes handling multiple debug sessions in one instance of VSCode. Multiple sessions can be independent of multi-core but from a look and feel the feel similar. Multiple sessions can be used using a Launch Group or Compound Launch and they can work. There are a couple of issues with debugging the type of targets we deal with

• All launches are done near simultaneously. Usually, there is a dependency and no dependency can be enforced (not easily anyway)
• Information may need to be passed between instances about TCP ports to connect to, etc.
• Synchronized Restart/Reset cannot be done

We will address some of these issues using Chained Configurations. The theory is as follows. You will need a primary configuration (launch or attach type) that will start the GDB Server (OpenOCD, STLink-GdbServer, pyocd, JLinkGDBServer, etc.). The first instance in most cases (except JLink) creates TCP ports for multiple debuggers (gdb) to connect to; one for each processor core. In the case of JLink, one server is launched for each processor core. The primary configuration can optionally launch additional configurations. In launch.json, it can look something like

            // What follows is a proposal. Not the FINAL incarnation
            "numberOfProcessors": 3,
            "targetProcessor": 1,
            "chainedConfigurations": {
                "enabled": true,
                "waitOnEvent": "postInit",
                "lifeCycleShared": true,
                "launches": [                               // Array of launches. Order is respected
                    {
                        "name": "Attach Network Core",     // Name of another configuration
                        "folder": "${workspaceRoot}/../net"
                    }
                ]
            }

Most of the properties are available at the top level and for each launch. When specified at the top level, they are inherited by all the launches and each launch item can override the group. There is nothing stops a child configuration from having its own chained configurations. Hence the term chained.

Configurations are organized as a tree with the primary configuration at the root. They are related in some way. The child launches do not even have to be cortex-debug configurations. Thay can be any valid configuration specified in launch.json