LLDB is not able to find default source location

[mbarnett]

I tried this:

$ cat hello.rs
fn main() {
println!("Hello world!");
}
$ rustc -g hello.rs
$ ./hello
Hello world!
$ lldb hello
(lldb) target create "hello"
Current executable set to 'hello' (x86_64).
(lldb) source list
(lldb)
(lldb) b 2
error: No selected frame to use to find the default file.
error: No file supplied and no default file available.

I expected LLDB to actually be able to associate an executable compiled with debugging information to be able to list source code and set breakpoints. Compare GDB's support on the same machine (gdb 7.11 built from homebrew and self-signed for debugging privileges):

$ gdb hello
GNU gdb (GDB) 7.11
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin15.4.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from hello...Reading symbols from /Users/matt/hello.dSYM/Contents/Resources/DWARF/hello...done.
done.
(gdb) l
1   fn main() {
2       println!("Hello world!");
3   }
(gdb) b 2
Breakpoint 1 at 0x1000013e8: file hello.rs, line 2.

LLDB seems functional otherwise, with sources compiled with Clang

$ clang++ -g hello.cpp
$ lldb a.out
(lldb) target create "a.out"
Current executable set to 'a.out' (x86_64).
(lldb) source list
   3    int main() {
   4      std::cout << "Hello, World!!" << std::endl;
   5    
   6      return 0;
   7    }
(lldb) 

If anyone's curious, the rust-lldb wrapper does nothing to alleviate this (nor is it intended to AFAIK):

$ rust-lldb hello          
(lldb) command source -s 0 '/tmp/rust-lldb-commands.r9S6q9'
Executing commands in '/tmp/rust-lldb-commands.r9S6q9'.
(lldb) command script import "/usr/local/Cellar/rust/1.8.0/lib/rustlib/etc/lldb_rust_formatters.py"
(lldb) type summary add --no-value --python-function lldb_rust_formatters.print_val -x ".*" --category Rust
(lldb) type category enable Rust
(lldb) target create "hello"
Current executable set to 'hello' (x86_64).
(lldb) source list
(lldb) b 2
error: No selected frame to use to find the default file.
error: No file supplied and no default file available.
(lldb) 

Meta

$ lldb -v
lldb-350.0.21.9
$ uname -a
Darwin mycomp 15.5.0 Darwin Kernel Version 15.5.0: Tue Apr 19 18:36:36 PDT 2016; root:xnu-3248.50.21~8/RELEASE_X86_64 x86_64
$ rustc --version --verbose
rustc 1.8.0
binary: rustc
commit-hash: unknown
commit-date: unknown
host: x86_64-apple-darwin
release: 1.8.0

This rust was installed from Homebrew. This issue also occurred with 1.7.0.

[pcwalton]

cc @michaelwoerister

[steveklabnik]

I see this on Linux as well.

[michaelwoerister]

This might be a symptom of the compiler not emitting the DW_AT_main_subprogram attribute.

[michaelwoerister]

OK, I found the problem: LLDB is looking for a function named "main" when it tries to determine the default location in the source code. Since the compiler generated main function (the one wrapping the user-defined main function) does not have debuginfo attached, LLDB won't find anything.

The correct way to handle this would probably be to emit DW_AT_main_subprogram attributes (which LLVM does not support at the moment) and then for LLDB to use that instead of relying on a specific symbol name.

Maybe rust-lldb could do something here, meanwhile. But it seems a rather low-priority problem.

[michaelwoerister]

I didn't find anything that rust-lldb would be able to do, unfortunately.

[steveklabnik]

It's low priority in that it's not a big deal, and it's easy to work around, but it does give people a negative impression, as the comment leading to the report suggests.

Maybe this is something that's not a big deal, but might not be hard and lead to some perception gains? I don't know anything about generating debuginfo, so I don't know how tough it actually is...

On May 23, 2016, 18:49 -0400, Michael Woeristernotifications@github.com, wrote:

OK, I found the problem: LLDB is looking for a function named "main" when it tries to determine the default location in the source code. Since the compiler generated main function (the one wrapping the user-defined main function) does not have debuginfo attached, LLDB won't find anything.

The correct way to handle this would probably be to emitDW_AT_main_subprogramattributes (which LLVM does not support at the moment) and then for LLDB to use that instead of relying on a specific symbol name.

Mayberust-lldbcould do something here, meanwhile. But it seems a rather low-priority problem.

—
You are receiving this because you commented.
Reply to this email directly orview it on GitHub(#33674 (comment))

[michaelwoerister]

I'll take at look how GDB finds the correct function and see if that can help us here in any way. However, really fixing this would mean not only extending rustc, but also LLVM and LLDB. LLVM does not currently give us a way of marking the entry function correctly (via adding the DW_AT_main_subprogram attribute to the debuginfo entry of the main function and the compilation unit containing it), and once we add that to LLVM, we also need to make LLDB use this information.
Maybe we should just do that, try to get these changes merged upstream (they probably are not too hard to implement) but it would still be some time before users would actually see the benefits (i.e. they need to be using an LLDB executable that actually contains the changes). Since Rust and especially debuginfo is a pure spare-time endeavor for me at the moment, I can't promise that I would get around to actually implementing this any time soon.
I'll remove the P-low tag though :) Maybe someone else wants to step up to the task.

[Tobi34]

Is there an easy workaround for this issue ? If yes, what is it ?

[michaelwoerister]

Is there an easy workaround for this issue ? If yes, what is it ?

Yes, you can just manually set a breakpoint wherever you want. You just have to specify the file you want to set the breakpoint in (which you would have to do anyway if your program has more than one source file).

[Tobi34]

Thank You very much. I can set breakpoints, but I am not able to see the source code.
I did expected something like:

settings set target.hand-written-source-paths ./src/main.rs http://main.rs/ ./src/somewhere.rs http://somewhere.rs/ ...

To get the sources into rust-lldb.
(But maybe I have misunderstood the basic problem of this issue. Because I m new to rust.)

Am 01.07.2016 um 23:10 schrieb Michael Woerister notifications@github.com:

Is there an easy workaround for this issue ? If yes, what is it ?

Yes, you can just manually set a breakpoint wherever you want. You just have to specify the file you want to set the breakpoint in (which you would have to do anyway if your program has more than one source file).

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub #33674 (comment), or mute the thread https://github.com/notifications/unsubscribe/ATTz6BAAunhrbIFMdo2J9F47EhLj6nb1ks5qRYJFgaJpZM4Ifsvq.

[michaelwoerister]

I can set breakpoints, but I am not able to see the source code.

The debuginfo in your binary should store the paths to your source files. How are you compiling your program? Maybe you don't have debuginfo enabled?

[Tobi34]

Debugging info should be available, look:

Versions:
cargo 0.10.0-nightly (10ddd7d 2016-04-08)
rustc 1.9.0 (e4e8b66 2016-05-18)
lldb-350.0.21.9

Content Cargo.toml:
[package]
name = "test1"
version = "0.1.0"
authors = ["lala"]
publish = false
[profile.dev](- same result if this section is omitted)
opt-level = 0
debug = true
rpath = false
lto = false
debug-assertions = true
codegen-units = 1

Build:
cargo build -v
Compiling test1 v0.1.0 (file:///Documents/Rust/Test1/Test1)
Running rustc src/main.rs --crate-name test1 --crate-type bin -C codegen-units=1 -g --out-dir /Documents/Rust/Test1/Test1/target/debug --emit=dep-info,link -L dependency=/Documents/Rust/Test1/Test1/target/debug -L dependency=/Documents/Rust/Test1/Test1/target/debug/deps

After running into Breakpoint in "main":
(lldb) source info
error: No debug info for the selected frame.

[michaelwoerister]

Yes, that looks like debuginfo should be contained in your executables.

lldb-350.0.21.9

This is unfortunately an unsupported version of LLDB (see #32520 for more information). The next version of LLDB will not have this problem anymore (older versions didn't have it either). If you are adventurous, you can also build your own version of LLDB.

[Mark-Simulacrum]

This works with lldb-370.0.42, so I'm going to close. LLDB 350 isn't supported, so I don't think it's worth keeping this open.

$ lldb test
(lldb) target create "test"
Current executable set to 'test' (x86_64).
(lldb) source list
   1   	fn main() {
   2   		println!("Hello, world");
   3   	}
(lldb)
(lldb) b 2
Breakpoint 1: where = test`test::main + 24 at test.rs:2, address = 0x0000000100000b18
(lldb) r
Process 84869 launched: '/Users/mark/testing/test' (x86_64)
Process 84869 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x0000000100000b18 test`test::main at test.rs:2
   1   	fn main() {
-> 2   		println!("Hello, world");
   3   	}

[golddranks]

LLDB works fine for me when compiling a single .rs file with rustc -g, but fails to find the source code when compiling a cargo project. I wonder if other people are experiencing the same.

More info: https://www.reddit.com/r/rust/comments/6b8blv/hey_rustaceans_got_an_easy_question_ask_here/dhm7842/

[golddranks]

So, the problem is that .dSYM directories that contain the debug info aren't saved to target/debug/ directory but in target/debug/deps/. This is counterintuitive if you expect to be able to debug the binary in target/debug/$BINARY_NAME.

[michaelwoerister]

Interesting. @alexcrichton, is Cargo moving the executable after generating it in target/debug/deps?

[golddranks]

I posted a cargo issue: rust-lang/cargo#4056

[michaelwoerister]

Excellent, thank you @golddranks!

[NickHu]

Can this please be reopened? I am also seeing empty output from source list in lldb. My lldb version is 12.0.1, rustc is version 1.53.0, on Linux x86_64.

[kit-981]

Can this please be reopened? I am also seeing empty output from source list in lldb. My lldb version is 12.0.1, rustc is version 1.53.0, on Linux x86_64.

I can't reproduce this.

/tmp/rust % cargo new example
     Created binary (application) `example` package
/tmp/rust % cd example
rust/example % ls -la
drwxr-xr-x@   - k  6 Dec 19:25 .git
.rw-r--r--@   8 k  6 Dec 19:25 .gitignore
.rw-r--r--@ 176 k  6 Dec 19:25 Cargo.toml
drwxr-xr-x@   - k  6 Dec 19:25 src
rust/example % cargo build
   Compiling example v0.1.0 (/tmp/rust/example)
    Finished dev [unoptimized + debuginfo] target(s) in 0.59s
rust/example % lldb target/debug/example
Voltron loaded.
(lldb) target create "target/debug/example"
Current executable set to '/tmp/rust/example/target/debug/example' (x86_64).
(lldb) b main
Breakpoint 1: 2 locations.
(lldb) run
Process 88077 launched: '/tmp/rust/example/target/debug/example' (x86_64)
Process 88077 stopped
* thread #1, name = 'example', stop reason = breakpoint 1.2
    frame #0: 0x000055555555bc70 example`main
example`main:
->  0x55555555bc70 <+0>:  pushq  %rax
    0x55555555bc71 <+1>:  movq   %rsi, %rdx
    0x55555555bc74 <+4>:  leaq   0x3834c(%rip), %rax       ; __rustc_debug_gdb_scripts_section__
    0x55555555bc7b <+11>: movb   (%rax), %al
(lldb) c
Process 88077 resuming
Process 88077 stopped
* thread #1, name = 'example', stop reason = breakpoint 1.1
    frame #0: 0x000055555555bc34 example`example::main::h1644cce4bdca4434 at main.rs:2:5
   1   	fn main() {
-> 2   	    println!("Hello, world!");
   3   	}

I did initially think that I could reproduce this given that the first breakpoint does not have any source-level debugging information but the program entry point is not defined in the crate's source code and our main is only called later.

Is there any chance that you made this mistake too @NickHu?

[philipturner]

I have the same issue. I'm trying to explore lldb according to Apple's tutorial on the Swift website, but nothing shows when I do various commands.

[philipturner]

@kit-981 I have something that might help. Follow this tutorial. Then, try making some Rust code that's as close as possible to the C++ code. You should be able to reproduce the tutorial and find why LLDB isn't doing what you expect.

For example, I'm currently using this Swift program, which is my best translation from C++:

import Foundation
import Swift

func my_subroutine() {
    print("Hello world" + "\n")
}

do {
    var x: Int32 = 4
    var p = unsafeBitCast(Int(0), to: UnsafeMutablePointer<Int32>.self)
    my_subroutine()
    p.pointee = 3
    print("\(x)" + ", " + "\(p.pointee)" + "\n")
}

Edit: right after making this comment, I found out that only the bt and f commands work. p p doesn't show anything.

[billti]

I'm also hitting this, but only for certain commands (which is why there may be confusion and "no repro" above). I'm using Rust 1.76.0 and LLDB 17.0.6.

Been trying for days to see if I'm doing something wrong, setting various paths & settings, launching from different directories, etc., all to no avail.

As a bit more context, MOST debugging is working fine. I can even set breakpoints using the source file and line syntax, and they indeed get hit. I can also show the source lines via symbol name OK, which reports the filename correctly. It's purely using the 'source list' with a file that says it can't find main.rs, which is really weird with the prior filename related functionality working fine.

I've tried using both 'cargo build' and 'rustc -g main.rs' directly with no difference. Example session below highlighting most things working, but see the last couple of lines where 'source list -f main.rs' is not.

$ lldb -- ./rusty                        
(lldb) target create "./rusty"
Current executable set to '/Users/billti/src/rusty/target/debug/rusty' (arm64).
(lldb) version
lldb version 17.0.6
(lldb) b main.rs:16
Breakpoint 1: where = rusty`rusty::main::hc7e09b5163cc1858 + 92 at main.rs:16:13, address = 0x0000000100005358
(lldb) br list
Current breakpoints:
1: file = 'main.rs', line = 16, exact_match = 0, locations = 1
  1.1: where = rusty`rusty::main::hc7e09b5163cc1858 + 92 at main.rs:16:13, address = rusty[0x0000000100005358], unresolved, hit count = 0 

(lldb) run
Process 50236 launched: '/Users/billti/src/rusty/target/debug/rusty' (arm64)
Process 50236 stopped
* thread #1, name = 'main', queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x0000000100005358 rusty`rusty::main::hc7e09b5163cc1858 at main.rs:16:13
   13  	fn main() {
   14  	    let mine = "test".to_owned();
   15  	    let shar: Rc<str> = Rc::from(mine);
-> 16  	    let v = vec![1, 2, 3, 4, 5];
   17  	    let varc: Arc<str> = Arc::from("testing");
   18  	    // std::process::exit(shar.len() as i32);
   19  	
(lldb) source list -n main
File: /Users/billti/src/rusty/src/main.rs
   8   	
   9   	fn get_array() -> [i32;5] {
   10  	    [1, 2, 3, 4, 5]
   11  	}
   12  	
   13  	fn main() {
   14  	    let mine = "test".to_owned();
   15  	    let shar: Rc<str> = Rc::from(mine);
   16  	    let v = vec![1, 2, 3, 4, 5];
   17  	    let varc: Arc<str> = Arc::from("testing");
   18  	    // std::process::exit(shar.len() as i32);
(lldb) source list -f main.rs
error: Could not find source file "main.rs".

If I do the same thing with a C file compiled with clang -g main.c it works fine.

(lldb) source list -f main.c
   1   	#include <stdio.h>
   2   	
   3   	int main() {
   4   	    int x = 10;
   5   	    printf("Hello, world");
   6   	    return 0;
   7   	}
   8