Python 2 won't work Did you try pointing to python3?

Please see lldb formatters docs.

The breakpoints in main.rs aren't getting resolved. Are you building with debug info?

This enables cross-building for aarch64-unknown-linux-gnu and arm-unknown-linux-gnueabihf. Because Python runs various scripts in the course of install image generation, a host arch Python distribution needs to be built first.

Areas that still need work:

• I've changed the base image to ubuntu:xenial, because it has cross-toolchains readily available. Obviously, a Python distro built that way may not run on older Linuxes, e.g. CentOS 6 and the like.
• Not all Python tests pass. But then they didn't seem to pass before my changes either. Am I running tests the wrong way? -
  (PYTHONHOME=$(pwd)/install LD_LIBRARY_PATH=$(pwd)/install/lib $(pwd)/install/bin/python3 build/run_tests.py from the root of extracted zstd package).
• I could not get the pip module to work on arm - python3 -m ensurepip fails because of missing _sysconfigdata__linux_aarch64-linux-gnu module. Not sure why it isn't getting built...

To get rid of error messages when using PowerShell as a terminal shell in VSCode, you can set "lldb.terminalPromptClear" : null in user/workspace settings. Of course, this disables protection from junk input in the terminal (see above). Tradeoffs...

Ok, I'll take a look. Last time I checked, rust-lldb's formatters did not implement synthetic children, and so were not suitable for display in VSCode's variables treeview.

Hi, Could you please be more specific, which formatters are you talking about? Which language and which type(s)?

CodeLLDB installs all the standard formatters that LLDB has, and then adds Rust formatters on top of that. Unless something new had been added in LLDB since v10.0.0, there should be no difference between the two for C++ datatypes.

• For ##vso[artifact.associate]:
  • What is the purpose of each artifact type?
  • What is the difference between container and filepath artifact types?
• For ##vso[artifact.upload]:
  • The purpose of containerfolder parameter is unclear.
  • The first code example shows the command without any parameters, but in reality artifactname seems to be required, whereas containerfolder is not - in contradiction to what parameter documentation says.
  • Can it be emitted multiple times to several multiple files to the same artifact? (Seems like yes?)
  • Can it be used to specify the relative file path within the artifact? (Again, seems that it can - by appending relative path after containerfolder, however in combination with multiple uses, it produces an error that the specified artifact already exists. Would be good to clarify how this was designed to be used.)

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 16bf0bbb-8b63-6384-aa33-b5b1e2b8cfe3
• Version Independent ID: f4da8dbd-a02f-bbdf-2cf2-60e081339237
• Content: Logging commands - Azure Pipelines
• Content Source: docs/pipelines/scripts/logging-commands.md
• Product: devops
• Technology: devops-cicd-scripts
• GitHub Login: @juliakm
• Microsoft Alias: jukullam

The last entry in the debug log is evaluation on hover, so I assume this is where it crashed. LLDB is not bug-free, unfortunately. :(

I haven't personally tried that, but I don't see why not. Here are some resources to get you started:

• https://github.com/vadimcn/vscode-lldb/blob/master/MANUAL.md#remote-debugging
• https://lldb.llvm.org/use/remote.html
• https://www.sh-zam.com/2019/05/debugging-krita-on-android.html

Please see this. Most likely this is a problem with the debug info and/or source file path mappings.

Hi, trying to change python lldb.lybpython to python 2.7:

"C_Cpp.errorSquiggles": "Disabled",
"cmake.configureOnOpen": true,
"lldb.library": "/Users/shlimov/Work/xcode_installs/xcode_Azul18A298_GlacierDogfood12A5121t/Xcode.app/Contents/Developer/usr/bin/lldb",
"lldb.libpython": "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/libpython2.7.dylib",
"lldb.verboseLogging": true,

getting the following issue when running: configuration: { type: 'lldb', name: 'Attach to Name (wait)', request: 'launch', custom: true, relativePathBase: '/Users/shlimov/git/leda/modem' } liblldb: /Users/shlimov/Work/xcode_installs/xcode_Azul18A298_GlacierDogfood12A5121t/Xcode.app/Contents/Developer/usr/bin/lldb libpython: null environment: {} params: {} [2020-08-16T09:16:03Z INFO codelldb::find_python] Query returned ["/AppleInternal/Library/Frameworks/Python.framework/Versions/3.7/Python3", "/AppleInternal/Library/Frameworks/Python.framework/Versions/3.7/Python", "/AppleInternal/Library/Frameworks/Python.framework/Versions/3.7/Python", "Python.framework/Versions/3.7/Python"] [2020-08-16T09:16:03Z INFO codelldb::find_python] Probing "/AppleInternal/Library/Frameworks/Python.framework/Versions/3.7/Python3" [2020-08-16T09:16:03Z ERROR codelldb::find_python] "dlopen(/AppleInternal/Library/Frameworks/Python.framework/Versions/3.7/Python3, 9): image not found" [2020-08-16T09:16:03Z INFO codelldb::find_python] Probing "/AppleInternal/Library/Frameworks/Python.framework/Versions/3.7/Python" [2020-08-16T09:16:03Z INFO codelldb::find_python] Py_GetVersion returned "3.7.3 (default, Jul 5 2020, 04:26:16) \n[Clang 11.0.3 (clang-1103.0.29.21) (-macos10.15-objc-selector-opts)]" [2020-08-16T09:16:03Z INFO codelldb::find_python] Parsed version as 3.7 [2020-08-16T09:16:03Z INFO codelldb::find_python] Accepted Listening on port 58057 [2020-08-16T09:16:03Z DEBUG codelldb] New debug session Could not find platform independent libraries <prefix> Could not find platform dependent libraries <exec_prefix> Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>] Python path configuration: PYTHONHOME = (not set) PYTHONPATH = ':/Library/Python/2.7/site-packages:/Users/shlimov/git/hdc_wsoc_fw_shared_tools:/Users/shlimov/git/bennu/hdc_wsoc_fw_bennu_scripts' program name = 'python3' isolated = 0 environment = 1 user site = 1 import site = 1 sys._base_executable = '/Users/shlimov/.vscode-insiders/extensions/vadimcn.vscode-lldb-1.5.3/adapter/codelldb' sys.base_prefix = '/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8' sys.base_exec_prefix = '/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8' sys.executable = '/Users/shlimov/.vscode-insiders/extensions/vadimcn.vscode-lldb-1.5.3/adapter/codelldb' sys.prefix = '/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8' sys.exec_prefix = '/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8' sys.path = [ '', '/Library/Python/2.7/site-packages', '/Users/shlimov/git/hdc_wsoc_fw_shared_tools', '/Users/shlimov/git/bennu/hdc_wsoc_fw_bennu_scripts', '/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/lib/python38.zip', '/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/lib/python3.8', '/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/lib/lib-dynload', ] Fatal Python error: init_fs_encoding: failed to get the Python codec of the filesystem encoding Python runtime state: core initialized ModuleNotFoundError: No module named 'encodings'

Current thread 0x0000000119befdc0 (most recent call first): <no Python frame> Debug adapter exit code=1, signal=null.

how can I change the default python for the extension to be 2.7 and not 3?

Huh, that's not supposed to be possible... At the very least, there should have been a connection codelldb has accepted from VSCode in order to start the debug session. Would you mind attaching a full verbose log?

What happens if you just add "lldb.adapterEnv": { "LLDB_DEBUGSERVER_PATH": "<system debugserver path>" } is workspace configuration?

Just to be clear, "Before the message" refers to the period between when you start the debug session and when the "Failed to redirect stdio to a terminal." message appears? There should be about 5 seconds between these events.

Which debug info format does clang use in this case, DWARF or PDB?
Also, please make sure you are compiling without optimizations.

Does it show anything at all (without grep)? What about after the error appears?

Maybe this is a little early, but if the rust component could compile to wasm then we could ship that with the extension making it much easier to work behind corporate fire walls that only allow vscode extensions through.

Maybe this would need to depend on a wasi extension?

It’s quite possible we cannot do this yet, but this is definitely where we should be going - I’m sure the wasi team would be keen on trying to make this happen as vscode wasi extensions would be a great combination.

Sorry, LLDB does not provide this sort of info.

Please try setting "lldb.terminalPromptClear": null in VSCode user settings (or change VSCode terminal shell to cmd)

Can you please try removing lldb.libpython from your configuration settings?

Hmm, no idea. Can you please check which TCP ports codelldb is listening on? lsof -iTCP | grep codelldb
You'll need to do this in the first 5 seconds after launch, before the "Failed to redirect stdio to a terminal." message appears.

Hmm, 3221225620 = 0xC0000094 = STATUS_INTEGER_DIVIDE_BY_ZERO. Is there anything unusual about your setup / debug launch configuration that might have triggered division by zero somewhere?
I am afraid I will not be able to investigate this without a repro case.

Sorry, you cannot use Python 2.
Python 2 and 3 are not compatible at the binary interface level, you have to choose one or the other when compiling LLDB. Given that Python 2 is out of support as of 1/1/2020, it makes little sense to choose it over Python 3.

You need to set sourceLanguages=["rust"], otherwise, how'd codelldb know you are debugging a Rust program?

Please see the Expressions section of the manual. In order to call C++ methods you'll need to use the native evaluator.

Clone failed: git clone --recursive https://github.com/vadimcn/vscode-lldb.git

fatal: remote error: upload-pack: not our ref 18233a45f690d7331d5abecb4b06b243f85a4420
fatal: the remote end hung up unexpectedly
Fetched in submodule path 'adapter/deps/schemafy', but it did not contain 18233a45f690d7331d5abecb4b06b243f85a4420. Direct fetching of that commit failed.

Sorry, I needed to re-create the repo and did not re-push custom tags. Should work now.

Fixes #17.

To get a stack trace, you need to specify the thread you are getting a stack trace of...  But for that, you'll need to know which thread is currently selected in the UI (assuming the process is in a stopped state in the first place).    I don't think VSCode currently exposes any API to query that.   Best you can do, is to listen for debug session events and record the last stopped thread id the way Debug Visualizer extension does it.

But I wonder if there's an easier way to do it...  Can you use stop hooks instead? E.g target stop-hook add -o 'e myvar.send("name")'

thread 'main' has overflowed its stack Debug adapter exit code=3221225725, signal=null.

Please see the Expressions section of the manual. Since it looks like you want to call a C++ method, you'll probably want to use native expressions, i.e. /nat set.size() == 3.

If you want to use PS for shell, you can set "lldb.terminalPromptClear": null in VSCode user settings.

Not much I can do about that for now. Hopefully DWARF5 support will improve over time as I pick up newer LLDB versions.

OS: macOS 10.14.6 VSCode version: 1.47.0-insider Extension version: v1.5.3 Toolchain version: clang version 10.0.0 Build target: Python version: Python 3.7.7

When inspecting std::set container variable, the output just shows underlying red-black tree structure.

Similarly some boost types like variant and optional also show internal raw data structures instead of human readable.

In order to decode data structures LLDB needs the appropriate data formatters. LLDB project provides them for some C++ types, but not all, and certainly not for boost. At the moment I have no plans for getting into adding new C++ formatters, sorry.

Would be nice to get more details about the OS, etc, as described in issue template.
But generally, yes, 32-bit code support in LLDB is not great at this point, especially on Windows. My extension merely wraps LLDB as VSCode extension, I can't do much about its core functionality.

You already can do that. Please review the expressions section of the manual; what you want in this case are the "native" expressions.

Thanks!

Awesome extension! Have been using this as debugger for C++ and zig. This change allows setting breakpoints also for zig language.

@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.

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.

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.

<!-- ⚠️⚠️ 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.

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.

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.

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

Before:

After:

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

Can you please try to follow these troubleshooting steps?

Both of them?

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

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