Missing dSYM on macos when building with cargo

old title: How to disassemble a rust binary with interleaved source code?

title says it all.

objdump -S doesn't include the source code. not sure why. cargo objdump doesn't work either.

clearly this sort of thing is possible, as vtune and instruments manage to do it.
but it would be nice to not have to use a profiler to inspect the annotated asm.

For me objdump -S works just fine:

$ cat > foo.rs
fn main() {
    println!("Hello World!");
$ rustc foo.rs -Cdebuginfo=1
$ objdump -S foo
0000000000008aa0 <_ZN3foo4main17h230a5796e4265ce5E>:
fn main() {
    8aa0:       48 83 ec 38             sub    $0x38,%rsp
    println!("Hello World!");
    8aa4:       48 8d 7c 24 08          lea    0x8(%rsp),%rdi
    8aa9:       48 8d 35 30 57 04 00    lea    0x45730(%rip),%rsi        # 4e1e0 <__do_global_dtors_aux_fini_array_entry+0x60>
    8ab0:       ba 01 00 00 00          mov    $0x1,%edx
    8ab5:       e8 16 ff ff ff          call   89d0 <_ZN4core3fmt9Arguments9new_const17ha500531a9b658113E>
    8aba:       48 8d 7c 24 08          lea    0x8(%rsp),%rdi
    8abf:       ff 15 c3 7e 04 00       call   *0x47ec3(%rip)        # 50988 <_GLOBAL_OFFSET_TABLE_+0x78>
    8ac5:       48 83 c4 38             add    $0x38,%rsp
    8ac9:       c3                      ret
    8aca:       66 0f 1f 44 00 00       nopw   0x0(%rax,%rax,1)

Were you maybe looking at a release build without debuginfo or a function from the standard library?

hmm, no, i was looking at some of my code in debug.

though i'm on macos and compiled the code with cargo.

edit: i tried your example with rustc and got:

0000000100004410 <__ZN3foo4main17h691b038334809e88E>:
100004410: ff 43 01 d1 	sub	sp, sp, #80
100004414: fd 7b 04 a9 	stp	x29, x30, [sp, #64]
100004418: fd 03 01 91 	add	x29, sp, #64
10000441c: e8 43 00 91 	add	x8, sp, #16
100004420: e8 07 00 f9 	str	x8, [sp, #8]
100004424: 00 02 00 90 	adrp	x0, 0x100044000 <__ZN4core3ops8function6FnOnce40call_once$u7b$$u7b$vtable.shim$u7d$$u7d$17h0c5694469e060c41E+0x1c>
100004428: 00 60 08 91 	add	x0, x0, #536
10000442c: 29 00 80 52 	mov	w9, #1
100004430: e1 03 09 aa 	mov	x1, x9
100004434: 58 00 00 94 	bl	0x100004594 <__ZN4core3fmt9Arguments9new_const17hba11969f91334152E>
100004438: e0 07 40 f9 	ldr	x0, [sp, #8]
10000443c: 29 5b 00 94 	bl	0x10001b0e0 <__ZN3std2io5stdio6_print17h5cbe3655f3c5bca5E>
100004440: fd 7b 44 a9 	ldp	x29, x30, [sp, #64]
100004444: ff 43 01 91 	add	sp, sp, #80
100004448: c0 03 5f d6 	ret

oh, i think this may be some macos issue.
it's not working for C either...

There is a .dSYM "file" (strictly speaking a directory, but Finder presents it as a file) right next to the executable with the same name, right?

Wouldn't be too surprised.

okay, i installed binutils. with gobjdump, i get source code for your example and for a simple C program.
there is indeed a .dSYM "file" in that case.

however it still doesn't work for cargo builds. not even with a fresh cargo new example project.
cargo builds however don't have .dSYM "files" in target/debug

oddly enough, profiling and debugging do work, even without the dSYM. (however instruments fails to display the asm, when run without cargo instruments)

nightly doesn't produce a dSym either.
neither does cargo rustc -- -Cdebuginfo=1

yeah, so turns out, cargo builds don't generate dSYMs.
manually generating them with dsymutil <binary> fixes the issue (with gobjdump).

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.