Skip to content

[lldb] Support CommandInterpreter print callbacks #9955

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

JDevlieghere
Copy link

Xcode uses a pseudoterminal for the debugger console.

  • The upside of this apporach is that it means that it can rely on LLDB's IOHandlers for multiline and script input.
  • The downside of this approach is that the command output is printed to the PTY and you don't get a SBCommandReturnObject. Adrian added support for inline diagnostics (Support inline diagnostics in CommandReturnObject llvm/llvm-project#110901) and we'd like to access those from the IDE.

This patch adds support for registering a callback in the command interpreter that gives access to the (SB)CommandReturnObject right before it will be printed. The callback implementation can choose whether it likes to handle printing the result or defer to lldb. If the callback indicated it handled the result, the command interpreter will skip printing the result.

We considered a few other alternatives to solve this problem:

  • The most obvious one is using HandleCommand, which returns a SBCommandReturnObject. The problem with this approach is the multiline input mentioned above. We would need a way to tell the IDE that it should expect multiline input, which isn't known until LLDB starts handling the command.
  • To address the multiline issue,we considered exposing (some of the) IOHandler machinery through the SB API. To solve this particular issue, that would require reimplementing a ton of logic that already exists today in the CommandInterpeter. Furthermore that seems like overkill compared to the proposed solution.

rdar://141254310

There's no reason these methods cannot be `const`. Currently this
prevents us from passing around a const ref. This patch is in
preparation for llvm#125006.

(cherry picked from commit 7469032)
Per the title, the variable is unused.

(cherry picked from commit c1e9b90)
…vm#125270)

Name and line number are part of different option groups and are not
compatible.

```
(lldb) breakpoint set -n foo -l 10
error: invalid combination of options for the given command
```

The help output for `breakpoint set` confirms this. This patch updates
the test to use two compatible options. With the improved error
reporting from llvm#125125 this becomes an issue.

(cherry picked from commit dbabad0)
…ting (llvm#125125)

Use `llvm::Error` instead of `CommandReturnObject` for error reporting.
The command return objects were populated with errors but never
displayed. With this patch they're at least logged.

(cherry picked from commit 6deee0d)
As suggested in llvm#125006. Depending on which PR lands first, I'll update
`TestCommandInterepterPrintCallback.py` to check that the
`CommandReturnObject` passed to the callback has the correct command.

(cherry picked from commit 906eeed)
Xcode uses a pseudoterminal for the debugger console.

- The upside of this apporach is that it means that it can rely on
LLDB's IOHandlers for multiline and script input.
- The downside of this approach is that the command output is printed to
the PTY and you don't get a SBCommandReturnObject. Adrian added support
for inline diagnostics (llvm#110901) and we'd like to access those from the
IDE.

This patch adds support for registering a callback in the command
interpreter that gives access to the `(SB)CommandReturnObject` right
before it will be printed. The callback implementation can choose
whether it likes to handle printing the result or defer to lldb. If the
callback indicated it handled the result, the command interpreter will
skip printing the result.

We considered a few other alternatives to solve this problem:

- The most obvious one is using `HandleCommand`, which returns a
`SBCommandReturnObject`. The problem with this approach is the multiline
input mentioned above. We would need a way to tell the IDE that it
should expect multiline input, which isn't known until LLDB starts
handling the command.
- To address the multiline issue,we considered exposing (some of the)
IOHandler machinery through the SB API. To solve this particular issue,
that would require reimplementing a ton of logic that already exists
today in the CommandInterpeter. Furthermore that seems like overkill
compared to the proposed solution.

rdar://141254310
(cherry picked from commit 97f6e53)
Now that we store the command in the CommandReturnObject (llvm#125132) we
can check the command in the print callback.

(cherry picked from commit 53d6e59)
@JDevlieghere JDevlieghere requested a review from a team as a code owner February 5, 2025 00:10
@JDevlieghere
Copy link
Author

@swift-ci test

@JDevlieghere
Copy link
Author

@swift-ci test

@JDevlieghere JDevlieghere merged commit 414f399 into stable/20240723 Feb 5, 2025
2 of 3 checks passed
@JDevlieghere JDevlieghere deleted the cherrypick-stable/20240723-74690327c8fb-c1e9b908d9c2-26c2da5a1225-dbabad0fc04e-6deee0d5b36c-906eeeda833b-97f6e533865c-53d6e59b5946 branch February 5, 2025 22:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant