Add lldb attach-to-PID option for debugpy on Linux - #2052
Open
pdepetro wants to merge 2 commits into
Open
Conversation
Add an option to prefer lldb (falling back to gdb) when attaching to a process by PID on Linux. debugpy's attach-by-PID flow injects the debug server into a target process. On Linux it has always shelled out to gdb; on macOS it uses lldb. In some environments lldb is the available/preferred injector on Linux. This adds an opt-in preference, surfaced as a VS Code launch configuration option "linuxAttachPreferLldb". The selector flows end to end: adapter/clients.py reads linuxAttachPreferLldb from the attach request and forwards --linux-attach-prefer-lldb to the injector subprocess; server/cli.py parses that switch and sets the PYDEVD_ATTACH_PREFER_LLDB environment variable; add_code_to_python_process.py reads it at call time in the new run_python_code_linux dispatcher, which uses lldb when it is preferred and present on PATH, and otherwise transparently falls back to gdb. Implementation notes: - run_python_code_linux_lldb mirrors the existing run_python_code_mac lldb invocation but resolves the Linux .so via get_target_filename() and reuses the shared linux_and_mac/lldb_prepare.py driver. No native code changes are needed: both paths call the same exported DoAttach entry point. - The PEP 768 sys.remote_exec fast path (Python 3.14+) runs first and is unaffected; the lldb preference only applies on the gdb/lldb fallback path.
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
Contributor
|
🔒 Automated review in progress — @rchiodo is auto-reviewing this PR. |
Contributor
|
GitHub cannot anchor PR review comments to unchanged lines in the diff. Falling back to a general PR comment for tests/debugpy/server/test_cli.py:L390.
This assertion hard-codes |
rchiodo
reviewed
Jul 31, 2026
| env.pop("PYTHONIOENCODING", None) | ||
| env.pop("PYTHONPATH", None) | ||
| print("Running: %s" % (" ".join(cmd))) | ||
| subprocess.check_call(" ".join(cmd), shell=True, env=env) |
Contributor
There was a problem hiding this comment.
Warning · Non-blocking recommendation
run_python_code_linux_lldb duplicates the macOS lldb injector, including command construction, quoting, environment scrubbing, and subprocess execution. This creates two sources of truth for lldb fixes. Please extract the shared lldb flow into a helper, or explicitly document why the implementations must remain mirrored.
rchiodo
approved these changes
Jul 31, 2026
rchiodo
left a comment
rchiodo
left a comment
Contributor
There was a problem hiding this comment.
Approved via Review Center.
rchiodo
added
the
review-auto:approved
Extract the shared lldb injector, and fix a test that could fail spuriously depending on the ambient environment. run_python_code_linux_lldb duplicated run_python_code_mac in full: command construction, quoting, environment scrubbing, and subprocess execution were byte-identical apart from the .so/.dylib error message. Both are now thin wrappers over a shared _run_python_code_lldb(), which takes the library-not-found message as its only platform-specific input. Command generation and error text were verified unchanged against the previous implementation for both platforms. test_attach_to_pid_propagates_lldb_preference asserted show_debug_info=0, but attach_to_pid() derives that from DEBUGPY_ATTACH_BY_PID_DEBUG_INFO, which the test did not isolate. The variable is now cleared alongside PYDEVD_ATTACH_PREFER_LLDB, so the assertion stays exact and additionally pins the default. Tests are restructured to match: the shared flow is covered once against _run_python_code_lldb, and the platform wrappers are covered only for what they contribute - the error message and argument forwarding. They pass show_debug_info=7 rather than 0 so the assertions can distinguish a forwarded value from the default (is_debug is also 0 in the same command).
rchiodo
approved these changes
Aug 3, 2026
rchiodo
left a comment
rchiodo
left a comment
Contributor
There was a problem hiding this comment.
Approved via Review Center.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add an option to prefer lldb (falling back to gdb) when attaching to a process by PID on Linux.
debugpy's attach-by-PID flow injects the debug server into a target process. On Linux it has always shelled out to gdb; on macOS it uses lldb. In some environments lldb is the available/preferred injector on Linux. This adds an opt-in preference, surfaced as a VS Code launch configuration option "linuxAttachPreferLldb".
The selector flows end to end: adapter/clients.py reads linuxAttachPreferLldb from the attach request and forwards --linux-attach-prefer-lldb to the injector subprocess; server/cli.py parses that switch and sets the PYDEVD_ATTACH_PREFER_LLDB environment variable; add_code_to_python_process.py reads it at call time in the new run_python_code_linux dispatcher, which uses lldb when it is preferred and present on PATH, and otherwise transparently falls back to gdb.
Implementation notes: