Skip to content
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.

Sign up for GitHub

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

Jump to bottom

codelldb inside of vscode-lldb extension doesn't work #160874

Closed
colemickens opened this issue Feb 19, 2022 · 7 comments · Fixed by #236915 or #264887
Closed

codelldb inside of vscode-lldb extension doesn't work #160874

colemickens opened this issue Feb 19, 2022 · 7 comments · Fixed by #236915 or #264887
Assignees
@nigelgbanks
Labels
0.kind: bug

Comments

@colemickens
Copy link
Member

Describe the bug

I want to use vscode-extensions.vadimcn.vscode-lldb.adapter (providing codelldb) for it's Debug Adapter support. Particularly it seems like Helix can utilize it with some early debugging support.

However, it doesn't seem to work. After adding that to my nix shell, and entering it, and trying to run it, I get:

[cole@porty:~/code/rust-nix-template]$ codelldb
Error: "\"/nix/store/rnqda0vmhg95ziahvl7r6y10x4xk1y6z-vscode-lldb-adapter-1.6.10/lldb/lib/liblldb.so: cannot open shared object file: No such file or directory\""
@colemickens colemickens mentioned this issue Feb 19, 2022
Open
@colemickens
Copy link
Member Author

cc: @nigelgbanks since I'm running your latest PR bumping this.

@colemickens
Copy link
Member Author

I suspect that vscode-lldb's fork of lldb needs to be updated?

@colemickens
Copy link
Member Author

Oh yeah, that would be because the adapter is patched-inline in the extension process and the unwrapped, useless, adapter is passed thru instead.

@colemickens
Copy link
Member Author

I have some work that fixes this:

  1. codelldb just uses regular lldb now, we can drop the "fork" with the "rust-enabled" check
  2. codelldb tries to exec-itself in certain scenarios and must be patched so that it properly calls its wrapped version

But most of all, it seems like lldb-vscode is ... just built as part of lldb already. I'm not even sure if there's a huge point in bothering with codelldb and vscode-lldb in general.

I really wish this were less messy. codelldb was a hassle to figure out, lldb-vscode has a bad name, the repo that you find online is old and says darwin-only. yeesh.

@nigelgbanks nigelgbanks self-assigned this Jun 10, 2022
@NickHu NickHu mentioned this issue Sep 14, 2022
Merged
13 tasks
@mstone mstone mentioned this issue Jan 18, 2023
Merged
13 tasks
@stereomato
Copy link

i got hit by this, but now it says

Error: "\"/nix/store/wibfbvchp045fnk1kcj69x9kb694g6ix-vscode-extension-vadimcn-vscode-lldb-1.9.1/share/vscode/extensions/vadimcn.vscode-lldb/adapter/libcodelldb.so: cannot open shared object file: No such file or directory\""

@natsukium natsukium mentioned this issue Jun 4, 2023
Closed
Congee added a commit to Congee/nixpkgs that referenced this issue Jun 9, 2023
@Congee
vscode-lldb: 1.9.1 -> 1.9.2
2361bdb 
The patched adapter now produces a dynamic library instead of a static archive

fixes NixOS#234908,NixOS#160874
Congee added a commit to Congee/nixpkgs that referenced this issue Jun 9, 2023
@Congee
vscode-lldb: 1.9.1 -> 1.9.2
a31fa54 
The patched adapter now produces a dynamic library instead of a static archive

fixes NixOS#234908,NixOS#160874
@Congee Congee mentioned this issue Jun 9, 2023
Merged
12 tasks
github-actions bot pushed a commit that referenced this issue Jun 16, 2023
@Congee @github-actions
vscode-lldb: 1.9.1 -> 1.9.2
8134b54 
The patched adapter now produces a dynamic library instead of a static archive

fixes #234908,#160874

(cherry picked from commit a31fa54)
@Congee
Copy link
Contributor

Congee commented Jun 19, 2023 •
edited
Loading

Actually #236915 only resolves the libcodelldb.so issue. The original issue of missing liblldb.so still exists somewhat. Yet a working codelldb binary can be found after that PR at

$(nix show-derivation github:NixOS/nixpkgs/nixpkgs-unstable#vscode-extensions.vadimcn.vscode-lldb | jq -r '.[].outputs.out.path')/share/vscode/extensions/vadimcn.vscode-lldb/adapter/codelldb

Help is wanted to resolve the path issue of the adapter sub package 🥲

@Congee Congee reopened this Jun 19, 2023
github-actions bot pushed a commit that referenced this issue Jul 4, 2023
@Congee @github-actions
vscode-lldb: 1.9.1 -> 1.9.2
7b3c148 
The patched adapter now produces a dynamic library instead of a static archive

fixes #234908,#160874

(cherry picked from commit a31fa54)
Artturin pushed a commit that referenced this issue Jul 4, 2023
@github-actions
[Backport release-23.05] vscode-extensions.vadimcn.vscode-lldb: 1.9.1…
65ce51c 
… -> 1.9.2 (#241487)

Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
Co-authored-by: Congee <congeec@qq.com>
Co-authored-by: Changsheng Wu <Congee@users.noreply.github.com>
fixes #234908,#160874
qrlex pushed a commit to qrlex/nixpkgs that referenced this issue Oct 9, 2023
@mstone @qrlex
vscode-extensions.vadimcn.vscode-lldb: fix on Darwin
0c110aa 
Summary:

  vscode-lldb has been broken on Darwin due to a build-time issue:

    * on Darwin, the vscode-lldb build scripts expect $HOME to exist and be
      writable, NixOS#202507

  and several runtime-issues:

    * codelldb can't find its dynamic libraries (NixOS#160874)

    * lldb-server from nixpkgs doesn't work due to missing the

        "com.apple.security.cs.debugger"

      macOS codesigning entitlement, (NixOS#38624), also with the symptom that
      tccd, the macOS "Transparency, Consent, and Control" daemon, denies
      requests it receives from vscode/codium with log messages like:

	  "AUTHREQ_CTX: msgID=..., function=<private>, service=kTCCServiceDeveloperTool, preflight=yes, query=1,"
          "Service kTCCServiceDeveloperTool does not allow prompting; returning denied."
          "AUTHREQ_RESULT: msgID=..., authValue=0, authReason=5, authVersion=1, error=(null),", etc.

    * lldb-server from nixpkgs may also provide a different CLI interface than
      codelldb expects on macOS.

    * vscode-lldb directs lldb to load rust pretty-printing scripts which need
      to be preserved through the build process in nixpkgs

Solution:

  * The build problem can be fixed by setting HOME="$(pwd)/home", as suggested
    in NixOS#202507.

  * The dynamic libraries issue can be fixed by setting LD_LIBRARY_PATH while
    wrapping codelldb

  * The permissions issue and CLI interface issue can both be fixed by using
    Xcode's debugserver,

      /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/debugserver

    on macOS, since it has the required entitlement and the expected interface.

  * Finally, the script-loading issue can be fixed by copying the required
    scripts to the location that vscode-lldb expects to find them in.

Fixes:

  * NixOS#148946: Error failed to get reply to handshake packet on x86_64-darwin
    with vscode-extensions.vadimcn.vscode-lldb

  * NixOS#160874: codelldb inside of vscode-lldb extension doesn't work

  * NixOS#202507: vscode-extensions.vadimcn.vscode-lldb fails to build on aarch64-darwin

(cherry picked from commit fa70e74)
@mrcjkb mrcjkb mentioned this issue Nov 1, 2023
Merged
13 tasks
@mrcjkb
Copy link
Member

mrcjkb commented Nov 25, 2023

@colemickens why was this closed? I don't think it's fixed.

@wegank wegank reopened this Dec 18, 2023
wegank pushed a commit to mstone/nixpkgs that referenced this issue Apr 10, 2024
@mstone @wegank
vscode-extensions.vadimcn.vscode-lldb: fix on Darwin
d0415e5 
Summary:

  vscode-lldb has been broken on Darwin due to a build-time issue:

    * on Darwin, the vscode-lldb build scripts expect $HOME to exist and be
      writable, NixOS#202507

  and several runtime-issues:

    * codelldb can't find its dynamic libraries (NixOS#160874)

    * lldb-server from nixpkgs doesn't work due to missing the

        "com.apple.security.cs.debugger"

      macOS codesigning entitlement, (NixOS#38624), also with the symptom that
      tccd, the macOS "Transparency, Consent, and Control" daemon, denies
      requests it receives from vscode/codium with log messages like:

	  "AUTHREQ_CTX: msgID=..., function=<private>, service=kTCCServiceDeveloperTool, preflight=yes, query=1,"
          "Service kTCCServiceDeveloperTool does not allow prompting; returning denied."
          "AUTHREQ_RESULT: msgID=..., authValue=0, authReason=5, authVersion=1, error=(null),", etc.

    * lldb-server from nixpkgs may also provide a different CLI interface than
      codelldb expects on macOS.

    * vscode-lldb directs lldb to load rust pretty-printing scripts which need
      to be preserved through the build process in nixpkgs

Solution:

  * The build problem can be fixed by setting HOME="$(pwd)/home", as suggested
    in NixOS#202507.

  * The dynamic libraries issue can be fixed by setting LD_LIBRARY_PATH while
    wrapping codelldb

  * The permissions issue and CLI interface issue can both be fixed by using
    Xcode's debugserver,

      /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/debugserver

    on macOS, since it has the required entitlement and the expected interface.

  * Finally, the script-loading issue can be fixed by copying the required
    scripts to the location that vscode-lldb expects to find them in.

Fixes:

  * NixOS#148946: Error failed to get reply to handshake packet on x86_64-darwin
    with vscode-extensions.vadimcn.vscode-lldb

  * NixOS#160874: codelldb inside of vscode-lldb extension doesn't work

  * NixOS#202507: vscode-extensions.vadimcn.vscode-lldb fails to build on aarch64-darwin
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@nigelgbanks nigelgbanks

Labels
0.kind: bug
Projects
None yet
Milestone
No milestone
6 participants
@colemickens @nigelgbanks @Congee @wegank @mrcjkb @stereomato