To debug cargo project cause lots of 'symbol not found' problems on OSX

[wind2412]

My workspace is on OSX. If I touch hello.rs, rustc -g hello.rs and then gdb -q hello of a single .rs file, there won't be any problem and it will load symbols successfully. However, when I use cargo new hello --bin, cd hello, then cargo build and then gdb -q target/debug/hello, it will be a blast on my iterm full of messages as follows:

>gdb -q target/debug/hello                                                                           
Reading symbols from target/debug/hello...
warning: `/Users/zhengxiaolin/Documents/eclipse/hello/target/debug/deps/hello-aa762faea86652ac.0.o': can't open to read symbols: No such file or directory.

warning: can't find symbol '_ZN104_$LT$$RF$$u27$b$u20$collections..string..String$u20$as$u20$core..str..pattern..Pattern$LT$$u27$a$GT$$GT$13into_searcher17h12b3d7238e011a15E' in minsymtab

warning: can't find symbol '_ZN116_$LT$collections..borrow..Cow$LT$$u27$a$C$$u20$str$GT$$u20$as$u20$core..ops..AddAssign$LT$$RF$$u27$a$u20$str$GT$$GT$10add_assign17hdd8b6423379d7623E' in minsymtab

warning: can't find symbol '_ZN11collections3fmt6format17h622e78b799d1c558E' in minsymtab

warning: can't find symbol '_ZN11collections3str21_$LT$impl$u20$str$GT$10trim_right17ha60cffd510213a23E' in minsymtab

warning: can't find symbol '_ZN11collections3str21_$LT$impl$u20$str$GT$11into_string17h77e8e55aae74110bE' in minsymtab

warning: can't find symbol '_ZN11collections3str21_$LT$impl$u20$str$GT$12encode_utf1617h4b31c1b570b71bf6E' in minsymtab

warning: can't find symbol '_ZN11collections3str21_$LT$impl$u20$str$GT$12escape_debug17h6eadad2fa42faab1E' in minsymtab

warning: can't find symbol '_ZN11collections3str21_$LT$impl$u20$str$GT$12to_lowercase17hdfeeabf72d2d11edE' in minsymtab

warning: can't find symbol '_ZN11collections3str21_$LT$impl$u20$str$GT$12to_uppercase17hf48dd8c27a89e68dE' in minsymtab

warning: can't find symbol '_ZN11collections3str21_$LT$impl$u20$str$GT$14escape_default17h52d3319153d73dafE' in minsymtab

warning: can't find symbol '_ZN11collections3str21_$LT$impl$u20$str$GT$14escape_unicode17h116b615659071afdE' in minsymtab

warning: can't find symbol '_ZN11collections3str21_$LT$impl$u20$str$GT$4trim17hbce03c1a35407699E' in minsymtab

warning: can't find symbol '_ZN11collections3str21_$LT$impl$u20$str$GT$6repeat17h6fe0557d17b09553E' in minsymtab

warning: can't find symbol '_ZN11collections3str21_$LT$impl$u20$str$GT$9trim_left17h015cef6fe5ab820fE' in minsymtab

warning: can't find symbol '_ZN11collections5btree3map16unwrap_unchecked28_$u7b$$u7b$closure$u7d$$u7d$14_MSG_FILE_LINE17he2a66a8a2be2ef68E' in minsymtab

warning: can't find symbol '_ZN11collections5slice10merge_sort14_MSG_FILE_LINE17h71c2ec20d499b44fE' in minsymtab

and so on.. My paste is only a small part. The no-symbol message has a lot..
Hope to solve the problem~ :)

[wind2412]

A new problem was founded. Also on my OSX, I touch a single hello.rs file and then rustc -g hello.rs -o test. using rust-gdb to debug has no problem and successful but use rust-lldb has lots of errors.

This time I will list all messages.

rust-lldb test                                       11:18:03 
(lldb) command source -s 0 '/tmp/rust-lldb-commands.L9YKLP'
Executing commands in '/tmp/rust-lldb-commands.L9YKLP'.
(lldb) command script import "/usr/local/Cellar/rust/1.15.1_1/lib/rustlib/etc/lldb_rust_formatters.py"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Resources/Python/lldb/__init__.py", line 98, in <module>
    import six
ImportError: No module named six
Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'run_one_line' is not defined
Traceback (most recent call last):
  File "<string>", line 1, in <module>
.......

And the last issue also exists. When I use cargo build, with no --release argument and there has a .dYSM, but I can neither use rust-gdb nor rust-lldb to debug the whole project-generate binary executable file. That's a bit annoying. :)

[wind2412]

The second problem has been fixed by using pip install six. That's a lldb's component lost problem. But the first problem still exists.

I had the same issue with Cargo and rust-gdb on OS X; I code signed the gdb binary, and it works fine with rust-lldb. However, lldb isn't supported directly in Emacs, and I wanted to try using the gud debugger with Rust. Any ideas?

[spontoreau]

Hello, i have exactly the same problem with gdb...

[Mark-Simulacrum]

What version of OS X and GDB/LLDB are you using? I cannot reproduce on macOS 10.12.5 with GDB 8.0 and LLDB lldb-370.0.42 Swift-3.1

[marvinguo]

I have the same problem with macOS 10.12.5 and GDB8 and the rust is 1.18.

[Mark-Simulacrum]

Ah, I can reproduce now -- not sure what changed or if I was testing wrong before. I'm seeing warning: .../hello/target/debug/deps/hello-ffb2b0defc4d175a.0.o': can't open to read symbols: No such file or directory.` which leads me to believe that we're pointing debuginfo into files we later delete perhaps, or GDB is assuming they'll still be around on OS X?

[marvinguo]

I tried, gdb can not debug rust program in mac. The binary cargo generated can not debug in lldb, while rustc -g build can. Its strange. Any blog to guide to use lldb or vscode debug cargo-generated build? Thanks.

[johnnysmoke]

I also was not able to use gdb on Macosx Sierra - version 10.12.1 - to debug a rust application directly BUT i succeeded doing so in 2 different other ways:

1. I do not debug the binary directly but its object file in the 'deps' folder. For this I do use rust-gdb with the command 'rust-gdb target/debug/deps/[program to debug]-[some random string]. Ex: rust-gdb target/debug/deps/YOURPROGRAM-bca0608b5f489e5c
2. I use lldb on the executable directly. I think i prefer this as lldb output when tracing code is better - or I do not know gdb enough! :-)

[RReverser]

@johnnysmoke Thans for the suggestion, indeed, debugging that target/debug/.../program-randomstring works.

[ceigel]

I have tried to find a solution that somewhat works for this. My first observation is that running rustc -g src/hello.rs produces the correct symbols and the program is debuggable. With cargo, my workaround is to add these lines to Cargo.toml:

[profile.dev]
split-debuginfo = "packed"

Running gdb with the executable from deps (gdb target/debug/deps/hello-0471cd3202c032d7) shows this output signifying that the symbols are correctly found:

Reading symbols from target/debug/deps/hello-0471cd3202c032d7...
Reading symbols from /Users/myself/src/rust/hello/target/debug/deps/hello-0471cd3202c032d7.dSYM/Contents/Resources/DWARF/hello-0471cd3202c032d7...