[DO NOT MERGE] Experiment with `RtlCaptureStackBackTrace`

[ChrisDenton]

Experiment with RtlCaptureStackBackTrace as per #535. This is not intended to be merged. I'm leaving this here temporarily in case anyone wants to use it to experiment further.

The great thing about RtlCaptureStackBackTrace is that it doesn't require symbol loading and simply works across architectures without much fuss. This decouples symbol loading from tracing and allows a more lightweight way of storing backtrace information if you don't mind looking up the symbols later. The big downside is that it only gets the ip. Also I'm seeing off-by-one line numbers in tests\accuracy. Probably because of the more limited info.

RtlVirtualUnwind has the same advantages as RtlCaptureStackBackTrace and also provide all the information you need (symbols aside). However, it is much more involved and it isn't supported by x86. Still, it might be a better direction to go in.

[ChrisDenton]

(I'm not really working on this, I just had a fit of insomnia last night and this is the result)

[ChrisDenton]

Here we go:

---- doit stdout ----
-----------------------------------
looking for:
    tests\accuracy\main.rs:41
    crates\dylib-dep\src\lib.rs:13
    tests\accuracy\main.rs:40
found:
   0: backtrace::backtrace::trace_unsynchronized<backtrace::capture::impl$1::create::closure_env$0>
             at src\backtrace\mod.rs:66
   1: backtrace::backtrace::trace<backtrace::capture::impl$1::create::closure_env$0>
             at src\backtrace\mod.rs:53
   2: backtrace::capture::Backtrace::create
             at src\capture.rs:176
   3: backtrace::capture::Backtrace::new
             at src\capture.rs:140
   4: accuracy::verify
             at tests\accuracy\main.rs:94
   5: accuracy::doit::closure$0
             at tests\accuracy\main.rs:42
   6: core::ops::function::FnOnce::call_once<accuracy::doit::closure_env$0,tuple$<tuple$<ref$<str$>,u32>,tuple$<ref$<str$>,u32> > >
             at /rustc/8ede3aae28fe6e4d52b38157d7bfe0d3bceef225\library\core\src\ops\function.rs:250
   7: dylib_dep::foo
             at crates\dylib-dep\src\lib.rs:14
   8: accuracy::doit
             at tests\accuracy\main.rs:40
   9: accuracy::doit::closure$0
             at tests\accuracy\main.rs:18
  10: core::ops::function::FnOnce::call_once<accuracy::doit::closure_env$0,tuple$<> >
             at /rustc/8ede3aae28fe6e4d52b38157d7bfe0d3bceef225\library\core\src\ops\function.rs:250
  11: test::__rust_begin_short_backtrace<enum2$<core::result::Result<tuple$<>,alloc::string::String> >,enum2$<core::result::Result<tuple$<>,alloc::string::String> > (*)()>
             at /rustc/8ede3aae28fe6e4d52b38157d7bfe0d3bceef225/library\test\src\lib.rs:658
  12: core::ops::function::FnOnce::call_once<test::run_test::closure_env$1,tuple$<> >
             at /rustc/8ede3aae28fe6e4d52b38157d7bfe0d3bceef225/library\core\src\ops\function.rs:250
  13: test::run_test::run_test_inner::closure$0
             at /rustc/8ede3aae28fe6e4d52b38157d7bfe0d3bceef225/library\test\src\lib.rs:572
  14: std::sys_common::backtrace::__rust_begin_short_backtrace<test::run_test::run_test_inner::closure_env$1,tuple$<> >
             at /rustc/8ede3aae28fe6e4d52b38157d7bfe0d3bceef225/library\std\src\sys_common\backtrace.rs:135
  15: core::ops::function::FnOnce::call_once<std::thread::impl$0::spawn_unchecked_::closure_env$1<test::run_test::run_test_inner::closure_env$1,tuple$<> >,tuple$<> >
             at /rustc/8ede3aae28fe6e4d52b38157d7bfe0d3bceef225/library\core\src\ops\function.rs:250
  16: std::sys::windows::thread::impl$0::new::thread_start
             at /rustc/8ede3aae28fe6e4d52b38157d7bfe0d3bceef225/library\std\src\sys\windows\thread.rs:57
  17: BaseThreadInitThunk
  18: RtlUserThreadStart

thread 'doit' panicked at 'failed to find tests\accuracy\main.rs:41', tests\accuracy\main.rs:106:25

[ChrisDenton]

Closing this now as I'm not planning on pursuing it further at this time. But I'll leave the branch in place in case anyone else does.