Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    ash lea
    @ashkitten
    hey, i'm trying to figure out if i can use this with a wrapped vscode where the extensions directory is in the nix store... it seems to get stuck on "Acquiring CodeLLDB platform package: installing" because it's trying to write to a read-only filesystem. i can give it any dependencies it needs, is there a way to make it not try to grab the platform package?
    vadimcn
    @vadimcn
    Yeah, it expects to be able to write to extension directory. Are you trying to package vscode with extensions pre-installed? You can grab full platform-specific package from releases: https://github.com/vadimcn/vscode-lldb/releases/tag/v1.5.0
    MGlolenstine
    @MGlolenstine
    I'm trying to run and debug a RUST program on an embedded device. Now I'm unsure how the configuration should be looking, so that VSCode would build the binary with a custom command, deploy it and run it with a debugger. Is there even a way to do that?
    MGlolenstine
    @MGlolenstine
    I'm using https://github.com/rust-embedded/cross for the cross compilation for our embedded armhf device.
    MGlolenstine
    @MGlolenstine
    So if I use the lldb's custom launch configuration, I should be able to compile it using cross... Now I'm unsure on how to run and debug it remotely.
    ash lea
    @ashkitten
    never mind, i figured it out. had to use the "full" vsix package i guess
    MGlolenstine
    @MGlolenstine
    Remote debugging isn't working for me. I do have gdb and gdbserver enabled on the remote machine, but I can't use breakpoints. They just won't react. This is my remote launch configuration
    {
                "type": "gdb",
                "request": "launch",
                "name": "Launch Program (SSH + X11)",
                "target": "./rust_gui_test",
                "cwd": "${workspaceRoot}",
                "ssh": {
                    "host": "192.168.11.1",
                    "cwd": "/home/root/",
                    "keyfile": "/home/arch/.ssh/id_rsa",
                    "user": "root",
                    "forwardX11": true,
                    "x11host": "192.168.11.1",
                    "x11port": 6000
                },
                "valuesFormatting": "parseText"
            }
    and this is the output when starting the debugging run
    Running gdb over ssh...
    warning: Missing auto-load script at offset 0 in section .debug_gdb_scripts
    of file /home/root/rust_gui_test.
    Use `info auto-load python-scripts [REGEXP]' to list them.
    
    No source file named /home/root/src/utils/widgets/list_view.rs.
    Running executable
    warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.
    MGlolenstine
    @MGlolenstine
    I am crosscompiling Rust for armhf, and upon copying sources to the home folder of the embedded target, the debugging works as it should
    vadimcn
    @vadimcn
    @MGlolenstine "type": "gdb" is the Native Debug extension
    MGlolenstine
    @MGlolenstine
    @vadimcn I know, that's why I'm using
    it to debug native executables.
    Or did I misunderstood it again?
    Cole Mickens
    @colemickens
    I can't figure out how to build this from source.
    I can't use pre-built binaries on NixOS.
    why does it not use pkg-config or something like that to find lldb?
    How do I build the targets listed in BUILDING.md?
    Cole Mickens
    @colemickens
    vsix_full gives a build error - failed to load source for a dependency on schemafy.
    vadimcn
    @vadimcn
    schemafy is a git submodule; you need to git module init
    er, git submodule init
    But why do you need to build from source? It's somewhat involved...
    Cole Mickens
    @colemickens
    I'm on NixOS, nothing exists at /usr/*, etc. I could try to patch the binary. but that's annoying and I philosophically don't like downloading and running pre-built binaries.
    Thanks for the submodule tip, wish git would warn me when I clone a repo with submodules.
    Wasn't too bad to build, it built with my uber-devenv nix-shell once I did the submodule init/update. Just need to remember how to install the vsix :)
    Cole Mickens
    @colemickens
    Got it all working, thanks!
    MGlolenstine
    @MGlolenstine
    @vadimcn I'm using gdb because there's no armhf version of lldb-mi
    Cole Mickens
    @colemickens
    Thank you for vscode-lldb. I'm still a bit curious if you know much about lldb-vscode in the lldb source tree?
    petr-tik
    @petr-tik

    hey, thanks for the awesome DAP server with so many features across so many languages! I am a prisoner of emacs and wanted to use and potentially integrate your tool with dap-mode - the emacs one-stop shop for debug adapters.

    Is it ok if I ask a couple of questions, as I bump into problems? Appreciate you must be busy and/or uninterested in emacs, so completely understand if you prefer not to spend time on this

    Alexandre Bique
    @abique
    Hi
    I got a bunch of lldb pretty printers in a python file
    Is it correct to do: "lldb.launch.initCommands": [
    "command script import \"${workspaceFolder}/tools/lldb/bitwig_lldb_printers.py\""
    ]
    ?
    Benjamin Kahn
    @xkahn
    I'm trying to use this extension with swift on Fedora. I can't get displaying variables to work.
    It looks like the same problem as: vadimcn/vscode-lldb#107
    I did run strace on the lldb-server process while trying to get information on variables
    It never showed much, which seems odd.
    I do see registers shown, but that seems to part of the breakpoint
    write(18, "$[{\"name\":\"ConGoL\",\"reason\":\"breakpoint\",\"registers\":{\"16\":\"f376565555550000\",\"6\":\"30d9ffffff7f0000\",\"7\":\"30cfffffff7f0000\"}],\"signal\":5,\"tid\":52379}]]#ef", 154) = 154
    Any ideas?
    Benjamin Kahn
    @xkahn
    So... I guess the best thing is to recompile the module for Fedora.
    Ugh. But it needs Cargo nightly... and won't take the version that comes with fedora (I guess for the -Z command which is only enabled on nightly?)
    And the build system is sad about the filesystem layout of lldb in Fedora.
    ...and the build system is CMake, my old nemesis.
    Benjamin Kahn
    @xkahn
    For those who are reading this much later and want to hear how it turned out: Fedora's swift packages include an embedded lldb. That version is not built with the python2.7 directory included. This causes problems for the vscode-lldb extension.
    Basically, lldb is super fragile with hardcoded paths built into the source code, so embedded lldb requires extensive patching to make work.
    Some real solutions: make lldb more robust with search capabilities to find the resources it needs; have a configuration file (even if it's just hardcoded to be in /etc); merge the swift language support back into lldb mainline
    wellbye
    @fatfatson
    does this only support python3?