codegen-units ruins debug symbols

[jdm]

mod a {
    pub struct S;
    impl S {
        pub fn foo(&self) {
            println!("hi");
        }
    }
}

mod b {
    use a::S;
    pub struct T;
    impl T {
        pub fn bar(&self) {
            let s = S;
            s.foo();
        }
    }
}

fn main() {
    let t = b::T;
    t.bar();
}

With codegen-units=2, we get breakpoints in one module that work fine, and another that do not:

godot2:tmp jdm$ rustc -C codegen-units=2 foo.rs -g
godot2:tmp jdm$ lldb foo
(lldb) target create "foo"
Current executable set to 'foo' (x86_64).
(lldb) b foo.rs:5
Breakpoint 1: where = foo`foo::a::{{impl}}::foo + 36 at foo.rs:5, address = 0x00000001000009a4
(lldb) b foo.rs:15
Breakpoint 2: no locations (pending).
WARNING:  Unable to resolve breakpoint to any actual locations.
(lldb) r
Process 32398 launched: '/private/tmp/foo' (x86_64)
Process 32398 stopped
* thread #1: tid = 0x7bc9ea, 0x00000001000009a4 foo`foo::a::{{impl}}::foo(self=0x00007fff5fbff918) + 36 at foo.rs:5, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x00000001000009a4 foo`foo::a::{{impl}}::foo(self=0x00007fff5fbff918) + 36 at foo.rs:5
   2   	    pub struct S;
   3   	    impl S {
   4   	        pub fn foo(&self) {
-> 5   	            println!("hi");
   6   	        }
   7   	    }
   8   	}
(lldb) up
frame #1: 0x00000001000009ed foo`foo::b::T::bar::h8d6dcee6b0c8bb66 + 29
foo`foo::b::T::bar::h8d6dcee6b0c8bb66 + 29:
-> 0x1000009ed:  addq   $0x20, %rsp
   0x1000009f1:  popq   %rbp
   0x1000009f2:  retq
   0x1000009f3:  nopw   %cs:(%rax,%rax)
(lldb) q
Quitting LLDB will kill one or more processes. Do you really want to proceed: [Y/n] y

With codegen-units=1, all breakpoints work as expected:

godot2:tmp jdm$ rustc -C codegen-units=1 foo.rs -g
godot2:tmp jdm$ lldb foo
(lldb) target create "foo"
b Current executable set to 'foo' (x86_64).
(lldb) b foo.rs:15
Breakpoint 1: where = foo`foo::b::{{impl}}::bar + 24 at foo.rs:16, address = 0x00000001000009e8
(lldb) b foo.rs:5
Breakpoint 2: where = foo`foo::a::{{impl}}::foo + 36 at foo.rs:5, address = 0x00000001000009a4
(lldb) r
Process 32422 launched: '/private/tmp/foo' (x86_64)
Process 32422 stopped
* thread #1: tid = 0x7bce5a, 0x00000001000009e8 foo`foo::b::{{impl}}::bar(self=0x00007fff5fbff938) + 24 at foo.rs:16, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x00000001000009e8 foo`foo::b::{{impl}}::bar(self=0x00007fff5fbff938) + 24 at foo.rs:16
   13  	    impl T {
   14  	        pub fn bar(&self) {
   15  	            let s = S;
-> 16  	            s.foo();
   17  	        }
   18  	    }
   19  	}
(lldb) c
Process 32422 resuming
Process 32422 stopped
* thread #1: tid = 0x7bce5a, 0x00000001000009a4 foo`foo::a::{{impl}}::foo(self=0x00007fff5fbff918) + 36 at foo.rs:5, queue = 'com.apple.main-thread', stop reason = breakpoint 2.1
    frame #0: 0x00000001000009a4 foo`foo::a::{{impl}}::foo(self=0x00007fff5fbff918) + 36 at foo.rs:5
   2   	    pub struct S;
   3   	    impl S {
   4   	        pub fn foo(&self) {
-> 5   	            println!("hi");
   6   	        }
   7   	    }
   8   	}
(lldb) bt
* thread #1: tid = 0x7bce5a, 0x00000001000009a4 foo`foo::a::{{impl}}::foo(self=0x00007fff5fbff918) + 36 at foo.rs:5, queue = 'com.apple.main-thread', stop reason = breakpoint 2.1
  * frame #0: 0x00000001000009a4 foo`foo::a::{{impl}}::foo(self=0x00007fff5fbff918) + 36 at foo.rs:5
    frame #1: 0x00000001000009ed foo`foo::b::{{impl}}::bar(self=0x00007fff5fbff938) + 29 at foo.rs:16
    frame #2: 0x0000000100000a11 foo`foo::main + 17 at foo.rs:23
    frame #3: 0x000000010000a0fb foo`panic_unwind::__rust_maybe_catch_panic + 27 at lib.rs:98
    frame #4: 0x0000000100008967 foo`std::rt::lang_start [inlined] std::panicking::try<(),fn()> + 44 at panicking.rs:436
    frame #5: 0x000000010000893b foo`std::rt::lang_start [inlined] std::panic::catch_unwind<fn(),()> at panic.rs:361
    frame #6: 0x000000010000893b foo`std::rt::lang_start + 347 at rt.rs:57
    frame #7: 0x0000000100000a4a foo`main + 42
    frame #8: 0x00007fff929365fd libdyld.dylib`start + 1
(lldb) up
frame #1: 0x00000001000009ed foo`foo::b::{{impl}}::bar(self=0x00007fff5fbff938) + 29 at foo.rs:16
   13  	    impl T {
   14  	        pub fn bar(&self) {
   15  	            let s = S;
-> 16  	            s.foo();
   17  	        }
   18  	    }
   19  	}
(lldb)

[alexcrichton]

cc @michaelwoerister

[michaelwoerister]

Does this also happen in GDB?

[jdm]

@michaelwoerister Yep!

[michaelwoerister]

:(

[michaelwoerister]

I cannot reproduce this with GDB on Linux. Can you tell me more about your setup? OS, RUSTC version, GDB and LLDB versions, etc.

[jdm]

• OS X 10.9.5
• rustc 1.16.0-nightly (1a2ed98 2017-01-13)
• lldb-320.4.160
• multiple gdb versions show the same issue:
  • GNU gdb (GDB) 7.11
  • GNU gdb (GDB) 7.7.1
  • GNU gdb 6.3.50-20050815 (Apple version gdb-1822) (Sun Aug 5 03:00:42 UTC 2012)

[michaelwoerister]

Alright, I found out what the problem is: The OSX linker doesn't like it when there are DW_TAG_compile_units with the same name in different object files. Specifically, it will assume that all compile units with the same name come from the same object file and thus won't create an OSO stabs symbol for any but the first object file. When dsymutil later tries to aggregate the debuginfo from the object files, there is only one entry in the binary -- it won't know that about all the other object files out there.

A possible solution to this is assigning different DW_TAG_compile_unit names for different object files, even if they come from the same source file. This solved the problem in a local experiment. It is at odds with the DWARF definition of what the DW_AT_name of a compile unit should be, however.

[jdm]

How would that affect setting breakpoints on lines of named source files?

[jdm]

15:54 <tromey> one wacky idea would be to try making up a phony source file name, then pretending that the entire body was actually from the "#included" real file
15:55 <tromey> another would be to play games with relative paths and the compilation directory
15:55 <tromey> getting off in the weeds at that point though

[michaelwoerister]

How would that affect setting breakpoints on lines of named source files?

In practice not at all, I guess. We would still be emitting the correct file names for source locations.

[nikomatsakis]

Tagging with A-incr-comp since this affects incremental.

[jdm]

I waste so much time doing builds of Servo on branches that have codegen-units enabled before realizing that I need to disable it so I can poke around in lldb. Could we please have someone spend some time on fixing this or rust-lang/cargo#3897?

[michaelwoerister]

I'm inclined to just make a PR with the fix I mentioned above (=generate a unique filename for the codegen unit that does not correspond to an actual file). It's (kind of) incorrect with regards to DWARF but it should hurt neither function nor file/line breakpoints, I think, since debuggers and profilers already have to deal with functions coming from files that are not equal to the file the CGU specifies.

Any serious concerns, @tromey?

[michaelwoerister]

@jdm, did you get a chance to see if the fix from #42100 works for you?

[jdm]

It's certainly much more usable out of the box now. Thanks!