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!