[Lldb-commits] [lldb] [lldb-dap] Listen for broadcast classes. (PR #140142)

[John Harrison via lldb-commits]

ashgti wrote:

> Is it possible to delay _setting_ the breakpoint until we know what the target is? Or will that be a problem because attach/launchCommands will already resume the process? Could we require that the target is created inside `preRunCommands` or `initCommands`?

Previously, we would handle the `launch`/`attach` request when it arrived, which meant we'd have a target configured by the time the `setBreakpoint` request was called. Also previously, we would leave the process in a stopped state until the `configurationDone` request was sent. #138219 adjusted that to delay handling the `launch`/`attach` until we get the configuration done. https://discourse.llvm.org/t/reliability-of-the-lldb-dap-tests/86125 has some background on that change.

During the startup flow we do need to reply to the `setBreakpoint` requests before VSCode will send the `configurationDone`. We could just mark the breakpoints as unverified and not 'really' set them until we finish launching. That could also work around this issue.

> Can we use the selected target until we've decided on the dap target? I guess that still leaves the possibility that the launch commands create multiple targets and that you temporarily see events belonging to the wrong target before another target was selected, but I'm not sure how to avoid that. Unless there's a way to queue up events? I'd need to look at the code in more detail to figure out how that works exactly (or ask @jimingham).

Another possible way to handle this would be to iterate over the known breakpoints after the `attachCommands`/`launchCommands` have finished and check if we need to update the breakpoint state.

For reference, our launch flow we use is roughly:

```jsonc
{
    "type": "lldb-dap",
    "request": "launch",
    "name": "...",
    "initCommands": [
      "command source config/lldbinit" // loads python scripts with additional helpers
    ],
    "launchCommands": [
        "!launch --device <ios-simulator-id> bazel-bin/path/to/ios_app.ipa"
    ],
    "preLaunchTask": "bazel build //path/to:ios_app"
},
```

The python script is doing roughly:

* unzipping the ipa
* running `simctl install` / `devicectl install`
* `debugger.CreateTarget('<install-path>', '', '<platform>', True)`
* `simctl launch --wait-for-debugger` / `devicectl device process launch --start-stopped`
* `debugger.GetSelectedTarget().AttachToProcessWithID(<pid>)`

https://github.com/llvm/llvm-project/pull/140142