Always pass /DEBUG to msvc linker

[brson]

From convo with @retep998, passing /DEBUG, even w/o emitting debuginfo, makes backtraces work. They 'see no reason' not to always pass this flag.

This should be a simple change to rustc::back::link.

[alexcrichton]

@retep998 I'm curious, but to what degree did this make backtraces work? I just tried this out and it didn't help unless debuginfo was also generated.

[retep998]

All tests done at opt-level=0 using x86_64-pc-windows-msvc
With /DEBUG but no debuginfo:

thread '<main>' panicked at 'wow!', src\main.rs:3
stack backtrace:
   1:     0x7ff6086e573e - sys::backtrace::write::hcf05c95842d5d9db4Bs
   2:     0x7ff6086ea031 - rust_begin_unwind
   3:     0x7ff6086e1f4f - rt::unwind::begin_unwind_inner::h0aa6600eac0475fexKw
   4:     0x7ff6086e109a - __ImageBase
   5:     0x7ff6086e102e - __ImageBase
   6:     0x7ff6086e11b9 - __ImageBase
   7:     0x7ff6086eac69 - rt::lang_start::hdcf3e41d3b4ba1ffzbx
   8:     0x7ff6086e4194 - rt::unwind::try::inner_try::heb5bc5c4cae3a32eqGw
   9:     0x7ff6086eab78 - rt::lang_start::hdcf3e41d3b4ba1ffzbx
  10:     0x7ff6086e11ea - main
  11:     0x7ff6086eebec - __scrt_common_main_seh
  12:     0x7ffc2c362d92 - BaseThreadInitThunk

With /DEBUG and debuginfo:

thread '<main>' panicked at 'wow!', src\main.rs:3
stack backtrace:
   1:     0x7ff6bbfe576e - sys::backtrace::write::hcf05c95842d5d9db4Bs
   2:     0x7ff6bbfea061 - rust_begin_unwind
   3:     0x7ff6bbfe1f7f - rt::unwind::begin_unwind_inner::h0aa6600eac0475fexKw
   4:     0x7ff6bbfe10a3 - begin_unwind<&str>
   5:     0x7ff6bbfe1030 - inner
   6:     0x7ff6bbfe11df - main
   7:     0x7ff6bbfeac99 - rt::lang_start::hdcf3e41d3b4ba1ffzbx
   8:     0x7ff6bbfe41c4 - rt::unwind::try::inner_try::heb5bc5c4cae3a32eqGw
   9:     0x7ff6bbfeaba8 - rt::lang_start::hdcf3e41d3b4ba1ffzbx
  10:     0x7ff6bbfe121a - main
  11:     0x7ff6bbfeec1c - __scrt_common_main_seh
  12:     0x7ffc2c362d92 - BaseThreadInitThunk

With neither

thread '<main>' panicked at 'wow!', src\main.rs:3
stack backtrace:
   1:     0x7ff773c3570e
   2:     0x7ff773c3a071
   3:     0x7ff773c31f1f
   4:     0x7ff773c3109a
   5:     0x7ff773c3102e
   6:     0x7ff773c311b9
   7:     0x7ff773c3ac39
   8:     0x7ff773c34164
   9:     0x7ff773c3ab48
  10:     0x7ff773c311ea
  11:     0x7ff773c3ebec
  12:     0x7ffc2c362d92 - BaseThreadInitThunk

[sfackler]

What's the __ImageBase thing that's ending up in the build with no debuginfo?

[retep998]

@sfackler Since no debug info is being emitted, and each object file only exports symbols for publicly accessible symbols. Those __ImageBase functions are either local functions or monomorphized functions. As such they aren't publicly exported, so no name is attached to them and thus the linker cannot emit any sort of debug symbols for them. For all the other functions, they are exported symbols in their various libraries, and so they provide symbol names that the linker can turn into debug symbols.

[alexcrichton]

Huh, now I'm not sure what I was testing... At least for a "hello world" executable it didn't have any affect on size, so 👍 from me!

[retep998]

It shouldn't have any effect on binary size since all the debug info is being emitted to a separate .pdb.

[apasel422]

I have a PR for this ready to go, but despite the lack of impact on binary file size, I'm wondering if we actually want to go ahead with this. There's no way to turn it off short of creating a new rustc flag, it causes additional filesystem churn, and it is potentially surprising for multiple files to be created.

[briansmith]

it causes additional filesystem churn, and it is potentially surprising for multiple files to be created.

As somebody that uses -msvc rustc a whole lot, those concerns don't matter to me at all. I'm already used to them when dealing with MSVC C/C++, and in practice they don't seem to matter anyway. Just make sure that the dependency tracking for incremental rebuilds is aware of the multiple outputs.

[retep998]

Here is some further testing on a simple .exe built using Cargo.

cargo build --release where debug = false

.text  58504
.rdata 19364
.data  512
.pdata 2412
.tls   2
.reloc 480

cargo rustc --release -- -Clink-args="/DEBUG" where debug = false

.text  58504
.rdata 19524
.data  512
.pdata 2412
.tls   2
.reloc 480

As you can see the only size increase here is a really tiny bit in .rdata indicating that there is a .PDB and providing the absolute path to it.

cargo build --release where debug = true

.text    58536
.rdata   19724
.data    512
.pdata   2424
.tls     2
.debug_s 746
.debug_l 25
.debug_a 332
.debug_i 792
.debug_r 64
.debug_p 300
.debug_p 169
.debug_l 258
.reloc   556

I find it really weird that when emitting debug info with -msvc we're still also emitting dwarf debug info into the .exe itself.

[brson]

rustc tends to provide precise control over the output artifacts with --emit, so I might expect pdb output to tie into that, but there's no --no-emit option. It's also different from the other outputs since pdb is a side-effect of turning on debuginfo - iow, nobody is saying 'i want a pdb', they just want debugging to work.

@alexcrichton Does rustc have an existing option for tools to use that prints out all the outputs of an invocation?

[alexcrichton]

We do have rustc --print file-names although it definitely doesn't include things like these pdb files. One thing I just remembered, though, is that we run dsymutil for OSX when debuginfo is enabled, generating *.dSYM folders. In that sense there's mild precedence for something like this.

[Diggsey]

For reference, MSVC will by default always produce a .pdb file, even for release builds, so there's a precedent for this. However, it somehow does this without passing /DEBUG to the linker (it just passes /PDB) - this seems to directly contradict what msdn says about /PDB being ignored when /DEBUG is not specified.