We've been treating the `seq` attribute incorrectly in lldb-dap. Previously, we always had `seq=0` for events and responses. We only filled in the `seq` field on reverse requests. However, looking at the spec and other DAP implementations, we are supposed to fill in the `seq` field for each request we send to the DAP client. I've updated our usage to fill in `seq` in `DAP::Send` so that all events/requests/responses have a properly filled `seq` value.
This patch extends stdio redirection support to integrated and external terminals. Currently, these cases are not covered by the standard logic because `attach` is used instead of `launch`. To be honest, `runInTerminal` in [VSCode](https://github.com/microsoft/vscode/blob/main/src/vs/workbench/contrib/debug/node/terminals.ts#L188) request supports `>` and `<` for redirection, but not `2>`. We could use the `argsCanBeInterpretedByShell` option to use full power of shell, however it requieres proper escaping of arguments on lldb-dap side. So, I think it will be better to have the only one option to control stdio redirection that works consistently across all console modes. Also, fixed a small typo in a comparison that was leading to out-of-bound access, and added `null` as a possible value for `stdio` array in package.json.
This PR resolves https://github.com/llvm/llvm-project/issues/149316 --------- Co-authored-by: Ebuka Ezike <yerimyah1@gmail.com>
Currently, the "stopped" event returned when a breakpoint is hit will always return only the ID of first breakpoint returned from `GetStopReasonDataAtIndex`. This is slightly different from the behaviour in `lldb`, where multiple breakpoints can exist at a single instruction address and all are returned as part of the stop reason when that address is hit. This patch allows all multiple hit breakpoints to be returned in the "stopped" event, both in the hitBreakpointIds field and in the description, using the same formatting as lldb e.g. "breakpoint 1.1 2.1". I'm not aware of any effect this will have on debugger plugins; as far as I can tell, it makes no difference within the VS Code UI - this just fixes a minor issue encountered while writing an `lldb-dap` backend for Dexter.
This patch deprecates the `runInTerminal` option in favour of `console` which allow the user the specify an integrated or external option.
This adds new protocol types for the 'variables' request. While implementing this, I removed the '$__lldb_extension' field we returned on the 'variables' request, since I think all the data can be retrieved from other DAP requests. --------- Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
Update tests to fix silently failing test and handle when a module is removed.
When there is a function that is inlined at the current program counter. If you get the current `line_entry` using the program counter's address it will point to the location of the inline function that may be in another file. (this is in implicit step-in and should not happen what step over is called). Use the current frame to get the `line_entry`
The [protocol](https://microsoft.github.io/debug-adapter-protocol//specification.html#Types_Source) expects that `sourceReference` be less than `(2^31)-1`, but we currently represent memory address as source reference, this can be truncated either when sending through json or by the client. Instead, generate new source references based on the memory address. Make the `ResolveSource` function return an optional source.
This adds new types for setExceptionBreakpoints and adds support for `supportsExceptionFilterOptions`, which allows exception breakpoints to set a condition. While testing this, I noticed that obj-c exception catch breakpoints may not be working correctly in lldb-dap.