profile
viewpoint

vadimcn/cargo-pgo 24

Supercharge you Rust programs!

vadimcn/llvm 12

Temporary fork of LLVM for Rust

vadimcn/compiler-rt 3

Mirror of official compiler-rt git repository located at http://llvm.org/git/compiler-rt. Updated hourly.

vadimcn/rust 2

a safe, concurrent, practical language

vadimcn/awesome-rust 1

A curated list of Rust code and resources.

vadimcn/clang 0

Mirror of official clang git repository located at http://llvm.org/git/clang. Updated every five minutes.

vadimcn/compiler-builtins 0

Porting `compiler-rt` intrinsics to Rust

issue commentvadimcn/vscode-lldb

Debugging child processes

@Trass3r: It isn't clear how this can be automated, let alone on all platforms (AFAIR, auto-attach only works on MacOS). This also goes beyond the scope of my project (which I see as integration of LLDB and VSCode, without adding core LLDB functionality).

Perhaps this can be achieved with scripting? When you only need to care about your specific environment, you can step into the body of fork(), read child process pid from a register, etc, and not have to worry that it's gonna look different in next version of libc.

TheAifam5

comment created time in 19 days

issue commentvadimcn/vscode-lldb

System environment variables

uses vscode-lldb for debugging

Are you sure about that? The installation instructions for nvim-dap point to lldb-vscode, which is a confusingly similarly named DAP adapter provided by the lldb project.

Shatur95

comment created time in 23 days

issue commentvadimcn/vscode-lldb

One package deployment if the rust component ship as wasm?

Even if Rust code could be compiled to wasm, what about liblldb? It uses a bunch of deeply platform-specific APIs, like ptrace. I doubt wasi has any plans to support those.

gilescope

comment created time in a month

issue openedmicrosoft/vscode

[Debug] Debug console completions don't work the way they are descripbed in DAP specification.

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ --> <!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ --> <!-- Please search existing issues to avoid creating duplicates. --> <!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: https://code.visualstudio.com/insiders/ -->

<!-- Use Help > Report Issue to prefill these. -->

  • VSCode Version: 1.46.1
  • OS Version: Ubuntu 20.04

(This is in the context of implementing "completions" request in a debugger extension)

Steps to Reproduce:

  1. Debug session starts.
  2. User types "se" in the debug console. VSCode sends a completion request to the debug adapter: "arguments":{"frameId":1001,"text":"se","column":3,"line":1} (I'm copying only the relevant parts of the messages here).
  3. The adapter responds with body":{"targets":[{"label":"ttings","length":0,"start":3}]} (I also tried just "body":{"targets":[{"label":"ttings"}]})
  4. Nothing happens. If I force suggestions with Ctrl+Space, VSCode says "No suggestions."

According to my reading of DAP spec, this response should have caused "ttings" to be inserted at the current cursor position. In reality, it seems that in order for completions to appear, the completion text must start with the current word under the cursor, i.e. "body":{"targets":[{"label":"settings"}]}. As far as I can tell, the "start" and the "length" attributes are completely ignored.

created time in a month

PR closed vadimcn/vscode-lldb

Update value.py for python3 support

When using vscode-lldb for debugging rust, I attempted to access a slice of a vector from the debug console:

buffer[0:100]

It returned name 'xrange' is not defined

Looking in value.py I found that there's a reference to xrange, which isn't valid in python3. This similar fix exists (but other way around) here: https://github.com/vadimcn/vscode-lldb/blob/35151d7d2de84376987e2bbc747192034e307584/formatters/rust.py#L10

This can be reproduced by entering a debugging state and trying to access a valid slice of a vector/array-like collection.

I'm all ears on how you'd like me to enhance this PR to make it acceptable.

+3 -0

1 comment

1 changed file

ablakey

pr closed time in a month

pull request commentvadimcn/vscode-lldb

Update value.py for python3 support

Since Python 2 is dead now, I think I'll just replace xrange with range. It'll still work in Python 2, would just use a bit more memory.

ablakey

comment created time in a month

PR closed vadimcn/vscode-lldb

Prepend the type name to the container summary.

For your consideration: adds a little bit of additional information to the thing that VSCode displays to users.

Before:

image

After:

image

(Notice that in the latter case you don't even know what variant of the enum it is #enum

+1 -1

1 comment

1 changed file

samscott89

pr closed time in a month

issue commentvadimcn/vscode-lldb

codelldb::dap_codec debug Process exited with code -1

Can you please try to follow these troubleshooting steps?

liuxiaozhe

comment created time in a month

issue commentvadimcn/vscode-lldb

There are some error messages when debugging in windows, but it can run debug correctly

Please add them (one at a time) in user or workspace configuration.

haozia816

comment created time in a month

issue commentvadimcn/vscode-lldb

There are some error messages when debugging in windows, but it can run debug correctly

Does adding either of these settings help? "lldb.terminalPromptClear": [""] or "lldb.terminalPromptClear": null

haozia816

comment created time in a month

issue closedvadimcn/vscode-lldb

Version 1.52 does not work with fish shell -- redirection problem

OS: Pop_os! 20.04 (similar to Ubuntu) VSCode version: 1.45.1 Extension version: 1.52 Toolchain version: rustc 1.45.0-nightly (a74d1862d 2020-05-14)

Build target: nightly-x86_64-unknown-linux-gnu (default) Python version:3.8.2 Shell: fish

When I start the debugger with F5, it gets an error in the terminal: <<>> /home/jmurray/.vscode/extensions/vadimcn.vscode-lldb-1.5.2/adapter/codelldb terminal-agent --port=43223 fish: Expected a command, but instead found a redirection <<>> /home/jmurray/.vscode/extensions/vadimcn.vscode-lldb-1.5.2/adapter/codelldb terminal-agent --port=43223

This did not happen on 1.50 or 1.51.

closed time in 2 months

jwmurray

issue closedvadimcn/vscode-lldb

macOs Catalina debug_session process exited with status -1 (Error 1)

OS: macOs Catalina 10.15.5 VSCode version: 1.45.1 Extension version: 1.5.3 Toolchain version: clang version 11.0.3 Python version: Python 3.7.3

I'm trying to use this extension to debug Node.js C++ addon like in this guide When I'm trying to run debug vscode throws "process exited with status -1 (Error 1)". Also, I tried to debug another binary (git clone from guide above) the result is the same. I'm kinda new to this stuff, maybe I'm missing something?

<details><summary>Debug log</summary><pre> configuration: { type: 'lldb', request: 'launch', name: 'Debug', program: '/Users/dmitriy/.nvm/versions/node/v14.4.0/bin/node', args: [ '/Users/dmitriy/Documents/amtProjects/customUdp/index.js' ], preLaunchTask: 'npm: build:dev', relativePathBase: '/Users/dmitriy/Documents/amtProjects/customUdp' } liblldb: /Users/dmitriy/.vscode/extensions/vadimcn.vscode-lldb-1.5.3/lldb/lib/liblldb.dylib libpython: /Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.7/Python3 environment: {} params: {} Listening on port 63353 [2020-06-09T17:30:34Z DEBUG codelldb] New debug session INFO(Python) 20:30:34 rust: Initializing, module name=rust DEBUG(Python) 20:30:34 rust: attaching summary get_tuple_summary to "^(.)$", is_regex=True DEBUG(Python) 20:30:34 rust: attaching synthetic StrSliceSynthProvider to "&str", is_regex=False DEBUG(Python) 20:30:34 rust: attaching summary _get_synth_summary_StrSliceSynthProvider to "&str", is_regex=False DEBUG(Python) 20:30:34 rust: attaching synthetic StrSliceSynthProvider to "str", is_regex=False DEBUG(Python) 20:30:34 rust: attaching summary _get_synth_summary_StrSliceSynthProvider to "str*", is_regex=False DEBUG(Python) 20:30:34 rust: attaching synthetic StdStringSynthProvider to "collections::string::String", is_regex=False DEBUG(Python) 20:30:34 rust: attaching summary _get_synth_summary_StdStringSynthProvider to "collections::string::String", is_regex=False DEBUG(Python) 20:30:34 rust: attaching synthetic StdStringSynthProvider to "alloc::string::String", is_regex=False DEBUG(Python) 20:30:34 rust: attaching summary _get_synth_summary_StdStringSynthProvider to "alloc::string::String", is_regex=False DEBUG(Python) 20:30:34 rust: attaching synthetic StdVectorSynthProvider to "^collections::vec::Vec<.+>$", is_regex=True DEBUG(Python) 20:30:34 rust: attaching summary _get_synth_summary_StdVectorSynthProvider to "^collections::vec::Vec<.+>$", is_regex=True DEBUG(Python) 20:30:34 rust: attaching synthetic StdVectorSynthProvider to "^alloc::vec::Vec<.+>$", is_regex=True DEBUG(Python) 20:30:34 rust: attaching summary _get_synth_summary_StdVectorSynthProvider to "^alloc::vec::Vec<.+>$", is_regex=True DEBUG(Python) 20:30:34 rust: attaching synthetic SliceSynthProvider to "^&(mut\s*)?[.]$", is_regex=True DEBUG(Python) 20:30:34 rust: attaching summary _get_synth_summary_SliceSynthProvider to "^&(mut\s)?[.]$", is_regex=True DEBUG(Python) 20:30:34 rust: attaching synthetic SliceSynthProvider to "^slice<.+>.$", is_regex=True DEBUG(Python) 20:30:34 rust: attaching summary _get_synth_summary_SliceSynthProvider to "^slice<.+>.*$", is_regex=True DEBUG(Python) 20:30:34 rust: attaching synthetic StdCStringSynthProvider to "std::ffi::c_str::CString", is_regex=False DEBUG(Python) 20:30:34 rust: attaching summary _get_synth_summary_StdCStringSynthProvider to "std::ffi::c_str::CString", is_regex=False DEBUG(Python) 20:30:34 rust: attaching synthetic StdCStrSynthProvider to "std::ffi::c_str::CStr", is_regex=False DEBUG(Python) 20:30:34 rust: attaching summary _get_synth_summary_StdCStrSynthProvider to "std::ffi::c_str::CStr", is_regex=False DEBUG(Python) 20:30:34 rust: attaching synthetic StdOsStringSynthProvider to "std::ffi::os_str::OsString", is_regex=False DEBUG(Python) 20:30:34 rust: attaching summary _get_synth_summary_StdOsStringSynthProvider to "std::ffi::os_str::OsString", is_regex=False DEBUG(Python) 20:30:34 rust: attaching synthetic StdOsStrSynthProvider to "std::ffi::os_str::OsStr", is_regex=False DEBUG(Python) 20:30:34 rust: attaching summary _get_synth_summary_StdOsStrSynthProvider to "std::ffi::os_str::OsStr", is_regex=False DEBUG(Python) 20:30:34 rust: attaching synthetic StdPathBufSynthProvider to "std::path::PathBuf", is_regex=False DEBUG(Python) 20:30:34 rust: attaching summary _get_synth_summary_StdPathBufSynthProvider to "std::path::PathBuf", is_regex=False DEBUG(Python) 20:30:34 rust: attaching synthetic StdPathSynthProvider to "std::path::Path", is_regex=False DEBUG(Python) 20:30:34 rust: attaching summary _get_synth_summary_StdPathSynthProvider to "std::path::Path", is_regex=False DEBUG(Python) 20:30:34 rust: attaching synthetic StdRcSynthProvider to "^alloc::rc::Rc<.+>$", is_regex=True DEBUG(Python) 20:30:34 rust: attaching summary _get_synth_summary_StdRcSynthProvider to "^alloc::rc::Rc<.+>$", is_regex=True DEBUG(Python) 20:30:34 rust: attaching synthetic StdRcSynthProvider to "^alloc::rc::Weak<.+>$", is_regex=True DEBUG(Python) 20:30:34 rust: attaching summary _get_synth_summary_StdRcSynthProvider to "^alloc::rc::Weak<.+>$", is_regex=True DEBUG(Python) 20:30:34 rust: attaching synthetic StdArcSynthProvider to "^alloc::(sync|arc)::Arc<.+>$", is_regex=True DEBUG(Python) 20:30:34 rust: attaching summary _get_synth_summary_StdArcSynthProvider to "^alloc::(sync|arc)::Arc<.+>$", is_regex=True DEBUG(Python) 20:30:34 rust: attaching synthetic StdArcSynthProvider to "^alloc::(sync|arc)::Weak<.+>$", is_regex=True DEBUG(Python) 20:30:34 rust: attaching summary _get_synth_summary_StdArcSynthProvider to "^alloc::(sync|arc)::Weak<.+>$", is_regex=True DEBUG(Python) 20:30:34 rust: attaching synthetic StdMutexSynthProvider to "^std::sync::mutex::Mutex<.+>$", is_regex=True DEBUG(Python) 20:30:34 rust: attaching summary _get_synth_summary_StdMutexSynthProvider to "^std::sync::mutex::Mutex<.+>$", is_regex=True DEBUG(Python) 20:30:34 rust: attaching synthetic StdCellSynthProvider to "^core::cell::Cell<.+>$", is_regex=True DEBUG(Python) 20:30:34 rust: attaching summary _get_synth_summary_StdCellSynthProvider to "^core::cell::Cell<.+>$", is_regex=True DEBUG(Python) 20:30:34 rust: attaching synthetic StdRefCellSynthProvider to "^core::cell::RefCell<.+>$", is_regex=True DEBUG(Python) 20:30:34 rust: attaching summary _get_synth_summary_StdRefCellSynthProvider to "^core::cell::RefCell<.+>$", is_regex=True DEBUG(Python) 20:30:34 rust: attaching synthetic StdRefCellBorrowSynthProvider to "^core::cell::Ref<.+>$", is_regex=True DEBUG(Python) 20:30:34 rust: attaching summary _get_synth_summary_StdRefCellBorrowSynthProvider to "^core::cell::Ref<.+>$", is_regex=True DEBUG(Python) 20:30:34 rust: attaching synthetic StdRefCellBorrowSynthProvider to "^core::cell::RefMut<.+>$", is_regex=True DEBUG(Python) 20:30:34 rust: attaching summary _get_synth_summary_StdRefCellBorrowSynthProvider to "^core::cell::RefMut<.+>$", is_regex=True DEBUG(Python) 20:30:34 rust: attaching synthetic StdHashMapSynthProvider to "^std::collections::hash::map::HashMap<.+>$", is_regex=True DEBUG(Python) 20:30:34 rust: attaching summary _get_synth_summary_StdHashMapSynthProvider to "^std::collections::hash::map::HashMap<.+>$", is_regex=True DEBUG(Python) 20:30:34 rust: attaching synthetic StdHashSetSynthProvider to "^std::collections::hash::set::HashSet<.+>$", is_regex=True DEBUG(Python) 20:30:34 rust: attaching summary _get_synth_summary_StdHashSetSynthProvider to "^std::collections::hash::set::HashSet<.+>$", is_regex=True DEBUG(Python) 20:30:34 rust: attaching synthetic StdOptionSynthProvider to "^core::option::Option<.+>$", is_regex=True DEBUG(Python) 20:30:34 rust: attaching summary _get_synth_summary_StdOptionSynthProvider to "^core::option::Option<.+>$", is_regex=True DEBUG(Python) 20:30:34 rust: attaching synthetic StdResultSynthProvider to "^core::result::Result<.+>$", is_regex=True DEBUG(Python) 20:30:34 rust: attaching summary _get_synth_summary_StdResultSynthProvider to "^core::result::Result<.+>$", is_regex=True DEBUG(Python) 20:30:34 rust: attaching synthetic StdCowSynthProvider to "^alloc::borrow::Cow<.+>$", is_regex=True DEBUG(Python) 20:30:34 rust: attaching summary _get_synth_summary_StdCowSynthProvider to "^alloc::borrow::Cow<.+>$", is_regex=True [2020-06-09T17:30:34Z DEBUG codelldb::dap_codec] --> {"command":"initialize","arguments":{"clientID":"vscode","clientName":"Visual Studio Code","adapterID":"lldb","pathFormat":"path","linesStartAt1":true,"columnsStartAt1":true,"supportsVariableType":true,"supportsVariablePaging":true,"supportsRunInTerminalRequest":true,"locale":"en","supportsProgressReporting":true},"type":"request","seq":1} [2020-06-09T17:30:34Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":1,"success":true,"command":"initialize","body":{"exceptionBreakpointFilters":[{"default":true,"filter":"cpp_throw","label":"C++: on throw"},{"default":false,"filter":"cpp_catch","label":"C++: on catch"}],"supportTerminateDebuggee":true,"supportsCompletionsRequest":true,"supportsConditionalBreakpoints":true,"supportsConfigurationDoneRequest":true,"supportsDataBreakpoints":true,"supportsDelayedStackTraceLoading":true,"supportsEvaluateForHovers":true,"supportsFunctionBreakpoints":true,"supportsGotoTargetsRequest":true,"supportsHitConditionalBreakpoints":true,"supportsLogPoints":true,"supportsRestartFrame":true,"supportsSetVariable":true}} [2020-06-09T17:30:34Z DEBUG codelldb::dap_codec] --> {"command":"launch","arguments":{"type":"lldb","request":"launch","name":"Debug","program":"/Users/dmitriy/.nvm/versions/node/v14.4.0/bin/node","args":["/Users/dmitriy/Documents/amtProjects/customUdp/index.js"],"preLaunchTask":"npm: build:dev","relativePathBase":"/Users/dmitriy/Documents/amtProjects/customUdp","_adapterSettings":{"displayFormat":"auto","showDisassembly":"auto","dereferencePointers":true,"suppressMissingSourceFiles":true,"evaluationTimeout":5,"consoleMode":"commands","sourceLanguages":null,"terminalPromptClear":["\n"]},"__sessionId":"7a0f5d2a-5570-4c49-a7de-eda6842dde0f"},"type":"request","seq":2} [2020-06-09T17:30:35Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":1,"event":"initialized"} [2020-06-09T17:30:35Z DEBUG codelldb::dap_codec] <-- {"type":"request","seq":2,"command":"runInTerminal","arguments":{"args":["\n"],"cwd":"","kind":"integrated","title":"Debug"}} [2020-06-09T17:30:35Z DEBUG codelldb::dap_codec] --> {"command":"setBreakpoints","arguments":{"source":{"name":"customudp_addon.cpp","path":"/Users/dmitriy/Documents/amtProjects/customUdp/src/customudp_addon.cpp"},"lines":[52],"breakpoints":[{"line":52}],"sourceModified":false},"type":"request","seq":3} [2020-06-09T17:30:35Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":3,"success":true,"command":"setBreakpoints","body":{"breakpoints":[{"id":1,"message":"Locations: 0","verified":false}]}} [2020-06-09T17:30:35Z DEBUG codelldb::dap_codec] --> {"type":"response","seq":4,"command":"runInTerminal","request_seq":2,"success":true,"body":{"shellProcessId":21724}} [2020-06-09T17:30:35Z DEBUG codelldb::dap_codec] <-- {"type":"request","seq":3,"command":"runInTerminal","arguments":{"args":["/Users/dmitriy/.vscode/extensions/vadimcn.vscode-lldb-1.5.3/adapter/codelldb","terminal-agent","--port=63355"],"cwd":"","kind":"integrated","title":"Debug"}} [2020-06-09T17:30:35Z DEBUG codelldb::dap_codec] --> {"command":"setFunctionBreakpoints","arguments":{"breakpoints":[]},"type":"request","seq":5} [2020-06-09T17:30:35Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":5,"success":true,"command":"setFunctionBreakpoints","body":{"breakpoints":[]}} [2020-06-09T17:30:35Z DEBUG codelldb::dap_codec] --> {"command":"setDataBreakpoints","arguments":{"breakpoints":[]},"type":"request","seq":6} [2020-06-09T17:30:35Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":6,"success":true,"command":"setDataBreakpoints","body":{"breakpoints":[]}} [2020-06-09T17:30:35Z DEBUG codelldb::dap_codec] --> {"command":"setExceptionBreakpoints","arguments":{"filters":["cpp_throw"]},"type":"request","seq":7} [2020-06-09T17:30:35Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":7,"success":true,"command":"setExceptionBreakpoints"} [2020-06-09T17:30:35Z DEBUG codelldb::dap_codec] --> {"command":"configurationDone","type":"request","seq":8} [2020-06-09T17:30:35Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":8,"success":true,"command":"configurationDone"} [2020-06-09T17:30:35Z DEBUG codelldb::dap_codec] --> {"command":"threads","type":"request","seq":9} [2020-06-09T17:30:35Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":9,"success":true,"command":"threads","body":{"threads":[]}} [2020-06-09T17:30:35Z DEBUG codelldb::dap_codec] --> {"type":"response","seq":10,"command":"runInTerminal","request_seq":3,"success":true,"body":{"shellProcessId":21724}} [2020-06-09T17:30:35Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":4,"event":"output","body":{"output":"Launching: /Users/dmitriy/.nvm/versions/node/v14.4.0/bin/node /Users/dmitriy/Documents/amtProjects/customUdp/index.js\n"}} [2020-06-09T17:30:35Z ERROR codelldb::debug_session] process exited with status -1 (Error 1) [2020-06-09T17:30:35Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":2,"success":false,"message":"process exited with status -1 (Error 1)","show_user":true} [2020-06-09T17:30:35Z DEBUG codelldb::dap_codec] --> {"command":"disconnect","arguments":{"restart":false},"type":"request","seq":11} [2020-06-09T17:30:35Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":11,"success":true,"command":"disconnect"} [2020-06-09T17:30:35Z DEBUG codelldb::dap_session] Client has disconnected [2020-06-09T17:30:35Z DEBUG codelldb::debug_session] End of the requests stream [2020-06-09T17:30:35Z DEBUG codelldb::debug_session] DebugSession::drop() [2020-06-09T17:30:35Z DEBUG codelldb] Session has ended [2020-06-09T17:30:35Z DEBUG codelldb] Exiting Debug adapter exit code=0, signal=null. </pre></details>

closed time in 2 months

tizl1234

issue commentvadimcn/vscode-lldb

Enums are not correctly displayed

Would you mind providing a verbose log?

HansPeterIngo

comment created time in 2 months

push eventvadimcn/awesome-rust

vadimcn

commit sha 4f320efeae5b7c8757e4a5d3a8c18e2d5995a5ac

Update Travis URL.

view details

push time in 2 months

issue closedvadimcn/vscode-lldb

rust-lldb support

OS: Fedora 32 (GNU/Linux) VSCode version: 1.45.1 Extension version: 1.5.3 Toolchain version: Rust 1.44.0 Build target: x86_64-unknown-linux-gnu Python version: 3.8.3

To my knowledge vscode-lldb currently doesn't support using rust-lldb, which is a wrapper around lldb with pretty printers that's located in ~/.cargo/bin/rust-lldb by default. Is there any way to use rust-lldb instead of usual lldb?

closed time in 2 months

protheory8

issue commentvadimcn/vscode-lldb

rust-lldb support

Does it work better than rust-lldb?

Of course I'm gonna say that, LOL.

protheory8

comment created time in 2 months

issue commentvadimcn/vscode-lldb

rust-lldb support

rust-lldb is not needed when using CodeLLDB. It has Rust support built-in.

protheory8

comment created time in 2 months

Pull request review commentrust-unofficial/awesome-rust

Add rust-cpp.

 See also [Foreign Function Interface](https://doc.rust-lang.org/book/first-editi * C++   * [rust-lang/rust-bindgen](https://github.com/rust-lang/rust-bindgen) — A Rust bindings generator   * [dtolnay/cxx](https://github.com/dtolnay/cxx) — Safe interop between Rust and C++ [<img src="https://api.travis-ci.com/dtolnay/cxx.svg?branch=master">](https://travis-ci.com/dtolnay/cxx)+  * [rust-cpp](https://crates.io/crates/cpp) - Embed C++ code directly in Rust.

Done.

vadimcn

comment created time in 2 months

push eventvadimcn/awesome-rust

vadimcn

commit sha 8f4dadbfbdad370c0bda69c60ecfdb744748c8ee

Added CI badges.

view details

push time in 2 months

PR opened rust-unofficial/awesome-rust

Add rust-cpp.
+1 -0

0 comment

1 changed file

pr created time in 2 months

push eventvadimcn/awesome-rust

vadimcn

commit sha abf49ec128ae9e4cefb8b3e7f6593eba9c2d9629

Add rust-cpp.

view details

push time in 2 months

issue commentvadimcn/vscode-lldb

Debugging Rust causes address exceptions.

Support of 32-bit Windows code in LLDB is kinda iffy. Please switch to 64-bit target, if possible.

tomgie

comment created time in 2 months

issue commentvadimcn/vscode-lldb

macOs Catalina debug_session process exited with status -1 (Error 1)

@mediawrbb: Thanks for figuring this out!

tizl1234

comment created time in 2 months

issue commentvadimcn/vscode-lldb

The debugger exited without completing startup handshake

Python 3.8.0 is buggy. Please upgrade to 3.8.2.

StridingDragon

comment created time in 2 months

issue commentvadimcn/vscode-lldb

Feature request: Just my code

Also I have these handy buttons above my unit tests saying "Run Test|Debug", but it's not quite clear which configuration this uses...

Those are coming from rust-analyzer; the debug configuration gets generated on the fly. You can see it in Output/LLDB panel in VSCode. You can override it via "rust-analyzer.debug.engineSettings", or save it via "Rust Analyzer: Generate Debug Configuration" command.

najamelan

comment created time in 2 months

issue commentvadimcn/vscode-lldb

macOs Catalina debug_session process exited with status -1 (Error 1)

Can you try adding "stopOnEntry": true to your launch config?
Also, please do try command-line LLDB to see if it has the same problem starting node.

tizl1234

comment created time in 2 months

issue commentvadimcn/vscode-lldb

No connection could be made...

Sorry, this goes into the launch configuration. If you want to set it as a default in settings, use "lldb.launch.terminal".

fdncred

comment created time in 2 months

issue commentvadimcn/vscode-lldb

macOs Catalina debug_session process exited with status -1 (Error 1)

Does specifying the working directory ("cwd") help? Can you try debugging with CLI lldb?

tizl1234

comment created time in 2 months

issue commentvadimcn/vscode-lldb

Debugging/Running a Rust program with WSL fails

Did anything change after upgrade to 1.5.3? What if you set "terminal":"console" in the launch config? Also, can you please confirm it is indeed WSL2 (wsl -l -v).

l33ds

comment created time in 2 months

issue commentvadimcn/vscode-lldb

No connection could be made...

Since this happened on different OS'es, I would suspect some sort of race condition existing when the terminal agent reverse-connects to the main debugger process. :-\

For now, you can set "terminal": "console" to use the Debug Console for target output.

fdncred

comment created time in 2 months

issue commentvadimcn/vscode-lldb

Suddenly stopped working

Should be fixed in 1.5.3

jabra98

comment created time in 2 months

issue commentvadimcn/vscode-lldb

Can't place breakpoints inside objective c files (.m/.mm)

Actually, .m files should have worked, but, yeah, Objective C++ is missing from the list of supported languages. I'll add that in the next release, but for now you can work around with "debug.allowBreakpointsEverywhere": true

knopp

comment created time in 2 months

push eventvadimcn/vscode-lldb

Vadim Chugunov

commit sha a57febd6bb42c3019c7be55cac5931acdd2ede31

Terminal prompt clearing.

view details

Vadim Chugunov

commit sha f9c57ee3dfba28a61aa4e148c11b4e0d52d88107

Give name to ad-hoc attach sessions.

view details

Vadim Chugunov

commit sha 4469ecc9c5f147d3338f52ee1c66dec2a75a62ca

Don't wait for runInTerminal response.

view details

Vadim Chugunov

commit sha f2deef41208cbfa5ebcc7ae4d847d1c051f33d74

crate::prelude

view details

Vadim Chugunov

commit sha 6b45dc10a576193bc9932d663b7a46b47f55da49

Rename bootstrap package.

view details

Vadim Chugunov

commit sha 3b83348df4d1087dd5f1d25ff3745b3c3625016f

Version 1.5.3

view details

push time in 2 months

created tagvadimcn/vscode-lldb

tagv1.5.3

A native debugger extension for VSCode based on LLDB

created time in 2 months

issue commentvadimcn/vscode-lldb

Debugging/Running a Rust program with WSL fails

WSL1 or WSL2? LLDB doesn't work on WSL1.

l33ds

comment created time in 2 months

delete tag vadimcn/vscode-lldb

delete tag : v1.5.3-rc1

delete time in 2 months

delete tag vadimcn/vscode-lldb

delete tag : v1.5.3

delete time in 2 months

created tagvadimcn/vscode-lldb

tagv1.5.3

A native debugger extension for VSCode based on LLDB

created time in 2 months

issue openedeamodio/vscode-gitlens

GitLens cannot display submodule diffs

<!-- Please search existing issues to avoid creating duplicates. --> <!-- Also for any git related or intermittent issues, please enable output channel logging by setting "gitlens.outputLevel": "debug" in your settings.json. This will enable logging to the GitLens & GitLens (Git) channels in the Output pane. Once enabled, please attempt to reproduce the issue (if possible) and attach the log lines from both channels. -->

  • GitLens Version: 10.2.1 <!-- Use Help > Report Issue to prefill these. -->
  • VSCode Version: 1.45.1
  • OS Version: Ubuntu 20.04

Steps to Reproduce:

  1. Create git repository with submodule(s), create a commit involving a submodule.
  2. In branch history locate and expand that commit. Click on the submodule.

Result: Error "Unable to open '<submodule> <hash> ... "
Looks like VSCode is trying to compare submodule directory as if it were a file.

Expected: Display submodule hash diff, the way VSCode's git integration does this:

diff --git a/submodule b/submodule
--- a/submodule
+++ b/submodule
@@ -1 +1 @@
-Subproject commit b1601e42183b31af1afc6ceedd4cb9b3efb27f0d
+Subproject commit 388ba770105a27e5589e55ad56dcf9dbd407d134

created time in 2 months

created tagvadimcn/vscode-lldb

tagv1.5.3-rc1

A native debugger extension for VSCode based on LLDB

created time in 2 months

issue commentvadimcn/vscode-lldb

Cannot inspect a std::wstring variable (node-gyp + Windows 10)

If you feel like it, you can try to create the debug visualizers yourself: https://lldb.llvm.org/use/variable.html. This example may be a good starting point.

antropit

comment created time in 2 months

issue commentvadimcn/vscode-lldb

Relative paths don't work for lldb.executable and lldb.library

Why not? In Python this would literally look like this:

In principle yes, but right now the code that computes these paths does not know about workspace folder, so that info would need to be plumbed through. Not sure it's worth it for a one-off, especially when there's a workaround.

arcivanov

comment created time in 2 months

issue commentvadimcn/vscode-lldb

Cannot inspect a std::wstring variable (node-gyp + Windows 10)

LLDB's STL visualizers support libstdc++ and libc++, but not Microsoft's implementation, as far as I know. Probably still tries to apply them, but fails.

antropit

comment created time in 2 months

issue commentvadimcn/vscode-lldb

Relative paths don't work for lldb.executable and lldb.library

Can the field accept a workspace-relative path?

No. However, you can set it to a different value in each workspace.

Out of curiosity, what are you doing that you need a per-workspace instance of liblldb?

arcivanov

comment created time in 2 months

issue commentvadimcn/vscode-lldb

Could not initialize Python interpreter

Hey. Sorry for delayed response.
Basically CodeLLDB needs Python interpreter runtime in order to provide debug visualizations. This page may help to troubleshoot Python issues.

AbduAmeen

comment created time in 2 months

issue commentvadimcn/vscode-lldb

"symbol lookup error" on debug

Anything new? I don't see in the log anything wrong with the debugger. It appears as if the process gets launched and then exits with an error.

joshhansen

comment created time in 2 months

issue commentvadimcn/vscode-lldb

"Run Without Debugging" doesn't wait for process to finish

Should be fixed in 1.5.2

tmcguire

comment created time in 2 months

issue closedvadimcn/vscode-lldb

【debugger startup problems】codelldb: Syntax error: word unexpected (expecting ")")

OS: Linux 4.15.0 VSCode version: 1.45.1 code server version: 3.3.1 Extension version: 1.5.0

Problem: When start a debugger for rust bin, the vsocde outputs:

Running `cargo build --bin=hello --package=hello --message-format=json`...
    Finished dev [unoptimized + debuginfo] target(s) in 0.06s
Raw artifacts:
{
  fileName: '~/projects/rust/target/debug/hello',
  name: 'hello',
  kind: 'bin'
}
Filtered artifacts: 
{
  fileName: '~/projects/rust/target/debug/hello',
  name: 'hello',
  kind: 'bin'
}
configuration: {
  type: 'lldb',
  request: 'launch',
  name: "Debug executable 'hello'",
  args: [],
  cwd: '${workspaceFolder}',
  relativePathBase: '~/projects/rust',
  program: '~/projects/rust/target/debug/hello',
  sourceLanguages: [ 'rust' ]
}
~/.local/share/code-server/extensions/vadimcn.vscode-lldb-1.5.0/adapter2/codelldb: 2: ~/.local/share/code-server/extensions/vadimcn.vscode-lldb-1.5.0/adapter2/codelldb: Syntax error: word unexpected (expecting ")")
Error: The debugger exited without completing startup handshake.

closed time in 2 months

275761919

issue commentvadimcn/vscode-lldb

Suddenly stopped working

How long are you waiting for the debug session to start? If it fails to connect to the terminal, after 5 seconds it should still proceed with target output sent to the debug console.

Thanks for investigation, I'll look into what's up with x-terminal-emulator.

jabra98

comment created time in 2 months

issue commentvadimcn/vscode-lldb

Suddenly stopped working

Does this happen with all C++ programs or just this one? Can you debug hello_world.cpp?

jabra98

comment created time in 2 months

issue commentvadimcn/vscode-lldb

Suddenly stopped working

Weird... Anything unusual about your shell configuration? How long did you wait for debug session to start?

jabra98

comment created time in 2 months

issue commentvadimcn/vscode-lldb

【debugger startup problems】codelldb: Syntax error: word unexpected (expecting ")")

I've reproduced this with the docker image. Looks like they cached the wrong version of the extension package - the arm64 one.
I recommend that you download the package from MS Marketplace and "Install from VSIX".

275761919

comment created time in 2 months

startedvadimcn/vscode-lldb

started time in 2 months

startedvadimcn/vscode-lldb

started time in 2 months

issue commentvadimcn/vscode-lldb

Debugging child processes

LLDB does not support child debugging; this isn't something I can implement in the extension on my own. You could try this though. Not as convenient, but does the job.

gilescope

comment created time in 2 months

push eventvadimcn/vscode-lldb

Vadim Chugunov

commit sha 25820f568057cfbdba6b416468deacacbd96f628

Add SBTarget::add_module().

view details

Vadim Chugunov

commit sha 0a36ed6d2dee487ee374db481f3bf53c17ca1485

OSX 10.14

view details

Vadim Chugunov

commit sha d289455c9fd86ee65c5b83cfc2739f017c99d1a6

Remove dependency on liblzma. Improved checking of binary dependencies.

view details

Vadim Chugunov

commit sha f2294feda08d35e52dcbaab14028a0f867fb6bda

Version 1.5.1

view details

Vadim Chugunov

commit sha 189efe2a913b1b426726a35e21d0e656559fbd8b

Fix unwrapping in debugger.evaluate()

view details

Vadim Chugunov

commit sha 707a75158de9f0cd4228eecc6d4d28f82c0cface

tokio 0.2

view details

Vadim Chugunov

commit sha a6a6d86ac04434411bc82cc2d1de143b9475bd85

Clean up dead code.

view details

Vadim Chugunov

commit sha 2f822e8e5e7c1d84e01c95ba23e882642bfcb500

launch.json

view details

Vadim Chugunov

commit sha 428ae7e7917c36342dd223f349a62fdaed096e37

Clean shutdown.

view details

Vadim Chugunov

commit sha 42b8a463ea93423df1a7f47fca5570532a67bbad

Support /cmd prefix.

view details

Vadim Chugunov

commit sha e2e5fd18540893f75ad43453b7a1f9cd50fd98eb

Hyperlinks, switch QnA to SO.

view details

Vadim Chugunov

commit sha 485c1fd669ce16812e2c355bddaa7b731c23b3ee

Remove lldb.executable

view details

Vadim Chugunov

commit sha 9c6a3d606c1146253a5dd3c23d7a9b32328a0d91

Track lldb source changes.

view details

Vadim Chugunov

commit sha 80a730a0392053c094df4598220e0f082da3c5a7

Python stdout to console.

view details

Vadim Chugunov

commit sha 2684ed9de4ce97b0f6f28a13c41db32053d6bc6a

Update lockfiles.

view details

Vadim Chugunov

commit sha e2b0853b4f4c43d4263e8088858a0b2f45e7a060

Asyncify terminal agent launch.

view details

Vadim Chugunov

commit sha ce09b06fda8ee814f7289f2dde74cfd0083058f0

Return Result from lldb APIs.

view details

Vadim Chugunov

commit sha 302d2c087257c1e8fe1598ce642499dda903a463

Show error upon failing to set the source map.

view details

Vadim Chugunov

commit sha 8eba919467d56a6893f00ebed52857669b42302a

Randomize temp file name.

view details

Vadim Chugunov

commit sha 407a46bf04aef2f0a1ff9b14018ac9b3da6d15ee

SBLaunchInfo::process_id()

view details

push time in 2 months

issue commentvadimcn/vscode-lldb

【debugger startup problems】codelldb: Syntax error: word unexpected (expecting ")")

This looks as if a shell was invoked to execute the codelldb binary.
Since you mentioned code server, I assume you are using VSCode remoting? What OS and CPU architecture is the remote machine?

275761919

comment created time in 2 months

issue commentvadimcn/vscode-lldb

Error in terminal

Weird, both commands are supposed to execute in the same terminal, and they do, even when I switch my shell to zsh.
Is there something unusual about your shell configuration?

0x0L

comment created time in 2 months

issue commentvadimcn/vscode-lldb

Can I debug ll file (llvm asm)?

Sorry, I don't know how to help you. There are no file extension restrictions imposed anywhere in Codelldb.

This looks to me like a problem with debug info, but I am not sure what... I wonder if there is a corresponding DICompileUnit? If you generated .ll files with clang, try doing a global search-replace on the file name - it more show up in more than one place.
Otherwise... try a different debugger. For example the one in MS C++ extension.

isral

comment created time in 2 months

issue commentvadimcn/vscode-lldb

Can I debug ll file (llvm asm)?

That setting works for me (just checked).

  • If you can't set a breakpoint in the first place, that's the VSCode restriction I mentioned, which can be bypassed using allowBreakpointsEverywhere. Or, you could switch the file type to C or C++ via the "Change Language Mode" vscode command.
  • If you can set a breakpoint, but it turns gray as soon as you start debugging, something is likely wrong with the source file path in the debug info. This page might help.
isral

comment created time in 2 months

issue commentvadimcn/vscode-lldb

Can I debug ll file (llvm asm)?

You mean, you'd like to set breakpoints in arbitrary files? That's a VSCode restriction. You can bypass it with "debug.allowBreakpointsEverywhere": true

isral

comment created time in 2 months

issue commentvadimcn/vscode-lldb

Suddenly stopped working

That's the default setting, but you overrode it in the launch config, so you'll need to change it there.

jabra98

comment created time in 2 months

issue commentvadimcn/vscode-lldb

Suddenly stopped working

What happens if you switch "terminal" to "integrated" or "console"?

jabra98

comment created time in 2 months

issue commentvadimcn/vscode-lldb

Suddenly stopped working

btw, what kind of shell are you using?

jabra98

comment created time in 2 months

issue commentvadimcn/vscode-lldb

Suddenly stopped working

Does CLI lldb or gdb work with your target? What's the output of file /home/joerg/dev/active/lcpp/build/Debug/lcpp?

jabra98

comment created time in 2 months

issue commentvadimcn/vscode-lldb

Suddenly stopped working

Can you please try again? The error message should have appeared in the log.

jabra98

comment created time in 2 months

issue commentvadimcn/vscode-lldb

Suddenly stopped working

Is this log from the same session where you saw that error pop up?

jabra98

comment created time in 2 months

GollumEvent
GollumEvent
GollumEvent
GollumEvent
GollumEvent
GollumEvent
GollumEvent

created tagvadimcn/vscode-lldb

tagv1.5.2

A native debugger extension for VSCode based on LLDB

created time in 2 months

delete tag vadimcn/vscode-lldb

delete tag : v1.5.2

delete time in 2 months

issue commentvadimcn/vscode-lldb

"cwd" not work when debugging rust program

That's Cargo error. You need to create a Cargo workspace at the top.

275761919

comment created time in 2 months

PR closed vadimcn/vscode-lldb

Fix: Handle omitted opt args

The Debug Protocol implementation in DebugSession is a bit too restrictive and rejects some messages with optional, but empty arguments.

For instance the following configurationDone request is valid according to the DAP specification, but declined by vscode-lldbs debug adapter:

{
    "seq": 7,
    "type": "request",
    "command": "configurationDone",
    "arguments": {}
}

This behavior leads to vscode-lldb not working with some DAP Client implementations, for instance Theia.

This MR adds two additional cases for configurationDone and threads to fix this.

+5 -1

1 comment

1 changed file

dschafhauser

pr closed time in 2 months

pull request commentvadimcn/vscode-lldb

Fix: Handle omitted opt args

My development branch has diverged too much from master, so this PR won't merge well, but I'll incorporate a similar fix into the next release. Thanks again for looking into this!

dschafhauser

comment created time in 2 months

Pull request review commentvadimcn/vscode-lldb

Fix: Handle omitted opt args

 impl DebugSession {                     Err(Error::Internal("Not implemented.".into()))                 }             },-            // A special case for DebugClient, which omits "disconnect" arguments.+            // Special cases for DebugClients, which omit optional arguments.             Command::Unknown { ref command } if command == "disconnect" =>                 self.handle_disconnect(None).map(|_| ResponseBody::disconnect),+            Command::Unknown { ref command } if command == "configurationDone" =>+                self.handle_configuration_done().map(|_| ResponseBody::configurationDone),+            Command::Unknown { ref command } if command == "threads" =>

Looks like Theia just always adds "arguments":{}. Ok, I guess there's no harm in tolerating a minor spec violation.

dschafhauser

comment created time in 2 months

issue commentvadimcn/vscode-lldb

QEMU gdbserver: stops in seemingly random places on SIGTRAP signals

One last idea: if you can figure out which SIGTRAPs are fake, you can use an "on-stop" script which will resume from undesired stops: target stop-hook add -o "script ..."

FlorentRevest

comment created time in 2 months

Pull request review commentvadimcn/vscode-lldb

Fix: Handle omitted opt args

 impl DebugSession {                     Err(Error::Internal("Not implemented.".into()))                 }             },-            // A special case for DebugClient, which omits "disconnect" arguments.+            // Special cases for DebugClients, which omit optional arguments.             Command::Unknown { ref command } if command == "disconnect" =>                 self.handle_disconnect(None).map(|_| ResponseBody::disconnect),+            Command::Unknown { ref command } if command == "configurationDone" =>+                self.handle_configuration_done().map(|_| ResponseBody::configurationDone),+            Command::Unknown { ref command } if command == "threads" =>

But according to DAP spec, "threads" is not supposed to have any arguments...

dschafhauser

comment created time in 2 months

issue commentvadimcn/vscode-lldb

QEMU gdbserver: stops in seemingly random places on SIGTRAP signals

Sorry, I'm out of ideas. I'd try to figure out why those extra SIGTRAPs get generated and how gdb handles them (MS C++ extension uses gdb underneath).

FlorentRevest

comment created time in 2 months

issue commentvadimcn/vscode-lldb

Can I debug ll file (llvm asm)?

Not as far as I know. "ll" merely signifies that lldb is a part of the llvm toolchain. That said, it seems that this used to be possible.

isral

comment created time in 2 months

issue commentvadimcn/vscode-lldb

Shell Command for Custom Configuration

When a task fails, VSCode should ask you whether you want to debug anyways, - unless you've disabled this prompt at some point.

anlumo

comment created time in 2 months

issue commentvadimcn/vscode-lldb

Shell Command for Custom Configuration

preLaunchTask is common for all vscode debuggers.

anlumo

comment created time in 2 months

issue commentvadimcn/vscode-lldb

Cannot reset to default backend or use an alternate backend

It can't find libpython, however basic debugging should still be functional. Please see this page for more info on setup: https://github.com/vadimcn/vscode-lldb/wiki/Setup

danielzfranklin

comment created time in 2 months

issue commentvadimcn/vscode-lldb

QEMU gdbserver: stops in seemingly random places on SIGTRAP signals

What happens if you disable stops on SIGTRAP via process handle SIGTRAP -s false?

FlorentRevest

comment created time in 2 months

issue closedvadimcn/vscode-lldb

Retieving the path to liblldb from the lldb executable

Theoretically, we could parse the lldb executable's ELF header and acquire the path to liblldb. Doing so could eliminate the need to separately config the path to executable and the path to liblldb and thus simplify the configuration.

closed time in 2 months

poscat0x04

issue commentvadimcn/vscode-lldb

Feature request: Just my code

LLDB has target.process.thread.step-avoid-regexp and target.process.thread.step-avoid-libraries settings, which are intended to do exactly that.

najamelan

comment created time in 2 months

issue commentvadimcn/vscode-lldb

Relative paths don't work for lldb.executable and lldb.library

lldb.library was supposed to be used with an absolute path. Can you just do that?

arcivanov

comment created time in 2 months

issue commentvadimcn/vscode-lldb

Shell Command for Custom Configuration

Can't you just use tasks.json to run your build command? Then make launch configuration dependent on that task via preLaunchTask.

BTW, "cargo": { ... } was designed to be used with tests, because cargo test generates binaries with hard to guess names. For launching non-test binaries I'd just use an explicit program path.

anlumo

comment created time in 2 months

more