LLDB source location resolution failse since nightly 2022-01-28

[RagibHasin]

LLDB on Windows is unable to resolve breakpoint to any actual locations since nightly 2022-01-28 build which is working fine with the previous nightly.

Code

I tried this code:

fn main() {
    let mut i = 9;
    i -= 3;
    assert_eq!(i, 6);
    println!("{i}");
}

I expected to see this happen:

(lldb) target create "D:\\rusty\\target\\debug\\rusty.exe"
Current executable set to 'D:\rusty\target\debug\rusty.exe' (x86_64).
(lldb) b -f main.rs -l 3
Breakpoint 1: where = rusty.exe`static void rusty::main() + 15 at main.rs:3, address = 0x000000014000100f
(lldb)

Instead, this happened:

(lldb) target create "D:\\rusty\\target\\debug\\rusty.exe"
Current executable set to 'D:\rusty\target\debug\rusty.exe' (x86_64).
(lldb) b -f main.rs -l 3
Breakpoint 1: no locations (pending).
WARNING:  Unable to resolve breakpoint to any actual locations.
(lldb)

Version it worked on

It most recently worked on: Rust nightly-2022-01-27

rustc --version --verbose:

rustc 1.60.0-nightly (6abb6385b 2022-01-26)
binary: rustc
commit-hash: 6abb6385b2cb7249f67b9b3ce7522527767dd907
commit-date: 2022-01-26
host: x86_64-pc-windows-msvc
release: 1.60.0-nightly
LLVM version: 13.0.0

Version with regression

It regressed on: Rust nightly-2022-01-28

rustc --version --verbose:

rustc 1.60.0-nightly (21b4a9cfd 2022-01-27)
binary: rustc
commit-hash: 21b4a9cfdcbb1e76f4b36b5c3cfd64d627285093
commit-date: 2022-01-27
host: x86_64-pc-windows-msvc
release: 1.60.0-nightly
LLVM version: 13.0.0

Backtrace

Not applicable.

Regressed between two nightlies (2022-01-27 and 2022-01-28) after Rust 1.58.1

[ehuss]

I suspect this is almost certainly from #93081 which includes rust-lang/llvm-project@2abffbf. cc @nikic

[nikic]

That change actually comes from #92767, so cc @arlosi.

[arlosi]

@RagibHasin what version of LLDB are you using on Windows. I'm unable to get it to work with stable or nightly (hitting "Unable to resolve breakpoint to any actual locations").

[RagibHasin]

@arlosi Regular LLDB bundled with LLVM cannot read Rust debug info, as far as I investigated. I actually faced breakpoint not loading with CodeLLDB first and then upon trying with their bundled LLDB, verified the problem.

[arlosi]

So the LLDB included with CodeLLDB has been specially patched to recognize Masm (the previous language identifier) as potentially Rust code. That's what the vanilla LLDB doesn't work before or after, and the CodeLLDB does.

Here's the commit that makes it work in CodeLLDB's LLVM fork: vadimcn/llvm-project@4aba5a4

I've submitted a patch to LLDB to get it working in the latest LLDB: https://reviews.llvm.org/D119044

I created an issue on the CodeLLDB GitHub as well vadimcn/codelldb#633 (cc @vadimcn) to get a fix in the patched version over there.

Since VSCode extensions can be quickly updated, assuming we can get a patched version out soon, I don't think we need to revert the change.

[RagibHasin]

Thank you very much @arlosi . I actually wasn't sure if it is an issue of Rust itself or LLDB/CodeLLDB. So, decided to raise it here. Hope it resolves soon.

[Jeremiah-Griffin]

I seem to be experiencing this now in the 1.59 stable release and not the 1.60 nightly.

The issues seems to express just as is detailed here:
vadimcn/codelldb#641 (comment)

and here:
vadimcn/codelldb#633 (comment)

A rebuild on a version as late as 1.58.1 stable fixes the issue.

Bit new to GitHub so if you need more detail I would be happy to supply it.

[F0903]

I seem to be experiencing this now in the 1.59 stable release and not the 1.60 nightly.

The issues seems to express just as is detailed here: vadimcn/vscode-lldb#641 (comment)

and here: vadimcn/vscode-lldb#633 (comment)

A rebuild on a version as late as 1.58.1 stable fixes the issue.

Bit new to GitHub so if you need more detail I would be happy to supply it.

I also have this issue on 1.59.

[arlosi]

This ended up getting (unintentionally) backported to the 1.59.0 stable release along with another unrelated LLVM change. More details are available over on the CodeLLDB page here: vadimcn/codelldb#633 (comment)

We need to get a new release of the CodeLLDB extension to fix it. Until a new CodeLLDB is available the options are:

• Use the 1.58.1 toolchain.
• Use the -gnu toolchain.
• Compile CodeLLDB and LLDB (which has the fix now) yourself.

[Jeremiah-Griffin]

This ended up getting (unintentionally) backported to the 1.59.0 stable release along with another unrelated LLVM change. More details are available over on the CodeLLDB page here: vadimcn/codelldb#633 (comment)

We need to get a new release of the CodeLLDB extension to fix it. Until a new CodeLLDB is available the options are:

• Use the 1.58.1 toolchain.
• Use the -gnu toolchain.
• Compile CodeLLDB and LLDB (which has the fix now) yourself.

Thank you kindly for taking the time to note this - have a good one!

[RagibHasin]

@arlosi is there any instruction about how to compile Rust-enabled LLDB somewhere? It seems that I cannot find it. Some pointers would be very helpful, for me and for future reference also, I think.

[johnw42]

I think this is worth making a new 1.59.x release to fix. Discovering what's going wrong is not easy. I was trying to debug Rust code on a new computer, and I assumed I was doing something wrong. I was starting to doubt my sanity until I tried debugging a Rust program on an older computer (where I had 1.57 installed) and it worked.

[arlosi]

There's a prerelease version of CodeLLDB that has a fix for this: vadimcn/codelldb#633 (comment)

You can download the appropriate .vsix file, and install it in VSCode:

Please report any feedback / issues over on the CodeLLDB thread. Hopefully we have a new official release soon.

[Xaeroxe]

I wish the release train had some standardized automated tests to check this output. Losing my debugging capability without warning is painful. Guess I'll go back to 1.58 for the time being.

[arlosi]

CodeLLDB has released an updated version (1.7.0) that fixes the issue. This can be closed.

[RagibHasin]

Yes. Thanks, everyone, for keeping Rust running smoothly.