Host SOS in a standalone LLDB driver - #5998
Conversation
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
Copilot review overview
🟡 Changes recommended
The new sos-lldb driver does not currently propagate failed -o startup command execution into a non-zero exit code, which breaks reliable scripting/batch usage.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Review tier: Lite
Findings: 1
New issues introduced by this change (1)
| Severity | Finding |
|---|---|
src/SOS/lldbplugin/driver.cpp — In batch/non-interactive usage, command failures from SBCommandInterpreter::HandleCommand() are not… |
What changed in this PR
This PR introduces a temporary macOS-only sos-lldb standalone LLDB driver executable to host SOS via Apple LLDB, while also tightening LLDB command output routing and validating CLRMA thread lookups to avoid invalid OS thread IDs.
Changes:
- Add a macOS
sos-lldbdriver executable (CMake + newdriver.cpp) for reliable LLDB hosting in batch/CLI scenarios. - Scope LLDB
SBCommandReturnObjectrouting via a reentrant RAII guard (LLDBServices::CurrentResultScope) and apply it to command entry points. - Reject CLRMA
GetThreadresolutions that produce invalid OS thread IDs (0or-1).
| File | Description |
|---|---|
| src/SOS/Strike/clrma/managedanalysis.cpp | Adds validation to reject invalid resolved OS thread IDs before querying CLRMA thread services. |
| src/SOS/lldbplugin/soscommand.cpp | Uses a scoped guard to ensure SOS command output is routed to the correct LLDB result object. |
| src/SOS/lldbplugin/services.h | Introduces LLDBServices::CurrentResultScope RAII guard and removes direct set/clear helpers. |
| src/SOS/lldbplugin/services.cpp | Applies the result scope to extension command execution and to LLDBServices::ExecuteCommand. |
| src/SOS/lldbplugin/driver.cpp | Adds the new sos-lldb standalone LLDB driver executable implementation. |
| src/SOS/lldbplugin/CMakeLists.txt | Builds/installs sos-lldb on macOS and links it against LLDB. |
Suppressed comments (1)
src/SOS/lldbplugin/driver.cpp:83
main()always returns 0 on normal shutdown, even if one of the-ostartup commands failed. After capturing per-command success, propagate it via a non-zero exit code (and in--batchmode, stop on the first failure).
lldb::SBCommandInterpreter interpreter = debugger.GetCommandInterpreter();
bool keepRunning = true;
for (const std::string& command : startupCommands)
{
if (!ExecuteCommand(interpreter, command))
💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.
| bool ExecuteCommand(lldb::SBCommandInterpreter& interpreter, const std::string& command) | ||
| { | ||
| lldb::SBCommandReturnObject result; | ||
| result.SetImmediateOutputFile(stdout, false); | ||
| result.SetImmediateErrorFile(stderr, false); | ||
| interpreter.HandleCommand(command.c_str(), result, false); | ||
| std::fflush(stdout); | ||
| std::fflush(stderr); | ||
|
|
||
| return result.GetStatus() != lldb::eReturnStatusQuit; | ||
| } |
|
Superseded by upstream-owned bottom stack layer #5999, which contains the same tested commit and participates in native stack #6003. |

Summary
sos-lldbexecutable on macOS to host SOS through Apple LLDB reliably0or-1)Why this layer is separate
This PR contains only the standalone product-facing LLDB hosting layer from #5981. Keeping it separate from Helix sharding, harness, test, documentation, and dependency work makes the temporary host independently reviewable and provides a clean bottom layer for subsequent changes. The executable is intentionally temporary while SOS needs a reliable Apple LLDB command host.
Validation
./build.sh -skipmanaged(macOS arm64 Debug)sos-lldb --no-lldbinit --batch -o versionlibsosplugin.dylibthroughsos-lldband ransoshelp, confirming plugin command output is routed through the scoped result