Repository: rust
Issue: MSVC profilers attribute most time to std::panicking::try::do_call<AssertUnwindSafe<closure>,()>
Labels: A-debuginfo,C-enhancement,T-compiler,O-windows-msvc

While building servo with a locally-built msvc nightly rust with debug symbols (same behaviour with regular nightly binaries, the debug symbols just give a lot more useful stacks/etc. overall since names are resolved to proper demangled ones), profilers end up attributing >70% of CPU time to `std::panicking::try::do_call<AssertUnwindSafe<closure>,()>`.  They both see the call stack from `thread_start -> thread::start_thread -> __rust_maybe_catch_panic -> std::panicking:...`.

If I break in the (Visual Studio) debugger, basically every Rust-created thread has a stack that looks like this:

```
    servo.exe!net::image_cache_thread::Receivers::recv() Line 277   Unknown
    servo.exe!net::image_cache_thread::ImageCache::run(core::option::Option<webrender_traits::api::RenderApi> core_resource_thread, ipc_channel::ipc::IpcReceiver<net_traits::image_cache_thread::ImageCacheCommand>) Line 369  Unknown
    servo.exe!00007ff7b1b93ae9() Line 352   Unknown
    servo.exe!00007ff7b2dfa6e0() Line 97    Unknown
    servo.exe!alloc::boxed::{{impl}}::call_box<(),closure>(closure * self, ...) Line 595    Unknown
    servo.exe!std::sys_common::thread::start_thread(libc::c_void * main) Line 21    Unknown
    servo.exe!std::sys::thread::{{impl}}::new::thread_start(libc::c_void * main) Line 50    Unknown
```

or

```
    win32u.dll!NtUserGetMessage()  Unknown
    user32.dll!GetMessageW()   Unknown
>   servo.exe!00007ff7b2bca4b0() Line 352   Unknown
    servo.exe!00007ff7b2dfa6e0() Line 97    Unknown
    servo.exe!alloc::boxed::{{impl}}::call_box<(),closure>(closure * self, ...) Line 595    Unknown
    servo.exe!std::sys_common::thread::start_thread(libc::c_void * main) Line 21    Unknown
    servo.exe!std::sys::thread::{{impl}}::new::thread_start(libc::c_void * main) Line 50    Unknown
```

I have a whole bunch of worker threads that are showing

```
>   servo.exe!00007ff7b2009fca() Line 352   Unknown
    servo.exe!00007ff7b2dfa6e0() Line 97    Unknown
    servo.exe!alloc::boxed::{{impl}}::call_box<(),closure>(closure * self, ...) Line 595    Unknown
    servo.exe!std::sys_common::thread::start_thread(libc::c_void * main) Line 21    Unknown
    servo.exe!std::sys::thread::{{impl}}::new::thread_start(libc::c_void * main) Line 50    Unknown
    kernel32.dll!BaseThreadInitThunk() Unknown
    ntdll.dll!RtlUserThreadStart() Unknown
```

as their entire stack.  The "Line 352", on each of those unnamed functions, takes me to `panicking.rs:352`, which is the `do_call` mentioned above.  But they're also very clearly different addresses, all of which are in the `servo.exe` module (which is at 00007FF7B1A20000-00007FF7B3EEB000).  

Manually dumping the pdb for servo.exe and looking up the relevant offset (`0x5e9fca`) gives me:

```
00000000005e7bb0      72712 SymTagFunction        net::bluetooth_thread::BluetoothManager::start C:\proj\r\servo\components\net\bluetooth_thread.rs(181)
00000000005f9890        254 SymTagFunction        net::bluetooth_thread::BluetoothManager::get_or_create_adapter C:\proj\r\servo\components\net\bluetooth_thread.rs(232)
```

Which is totally reasonable and correct -- that last thread is somewhere inside the BluetoothManager's thread func.  The size -- 72712 -- also looks correct, and our address should be in the middle of it.  The source file and line number are _also_ correct!

But the tools are merging all of these things down to line 352.  I'm wondering if they're not using the PDB info for this, and the compiler/llvm is generating incorrect info in another layer?