Bug reports of specific problems would be very appreciated! We emit fairly complete DWARF, but debuggers tend to be finicky about the exact subset of DWARF they accept.
I'll try to submit a report later. It's exactly what it sounds like, though.
$ cat hello.rs
fn main() {
println!("Hello world!");
}
$ 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
rustc 1.8.0
$ 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 don't see how the core team could be unaware of this unless literally no one has done even a cursory glance at OS X & LLDB in months.
Re:One year of Rust
by Manishearth on Monday May 16, 2016 @06:38PM
(#11710191)
I think this is a known issue relating to some lldb versions no longer treating unknown languages as C; which got fixed in lldb upstream but may not have been released yet.
Well, I do use it regularly for testing Servo. There's a debugger harness run as part of the test suite too. (Not to say we shouldn't fix whatever is causing your problem, though!)
I can make it work if I feed full file paths to the debugger using syntax I can't remember off the top of my head. Maybe that's one way some scripts might be functioning?
I'll copy and past this into a Github issue when I have a sec.
Eh, debugging is a mess, at least on OS X. Rust advertises LLDB support, but it seems semi-broken. Listing source is non-functional and just setting a break-point requires a lot of hand-holding.