Consider Printing the Stack Trace Upon Failure

[kuzminrobin]

Request bettinaheim:
The thrown std::runtime_error that is used everywhere throughout the QIR runtime results in a somewhat uninformative pop up window that merely states "Debug Error ... abort() has been called" without showing the string that has been passed to runtime_error, or any kind of stack trace. Catching the exception and manually logging exception.what() to std::out allows to show the failure message, but is not currently done at the top level of our programs. It would also be good to have more of a stack trace to facilitate identifying the issue.

Additional infos from kuzminrobin:
Printing the stack trace is a feature that has been discussed for a number of years in C++ community. If it is added to the language then not earlier than in C++20 (not yet fully implemented by any compiler). Years ago I implemented that feature one time for Linux, using the Linux-specific calls. I can try to get that implemented again, and for Windows too (I'm sure WinSDK provides that feature), if needed.
As for the pop-up window on Windows, if you have MS VC++ installed, then the pop-up typically has an extra button to debug the crashed executable. Upon pressing that button the exe is loaded to the debugger of Visual Studio where you can open the call stack window and see the offending stack trace (at least the frames in C/C++, but not the ones in LLVM IR), you should also be able to see the exception message, local variables of different stack frames, etc.

[kuzminrobin]

cgranade:
I'll add this to the above issue, but the Mono Project documentation has a good summary of how C# ↔ C++ interop handles propagation of stack trace information from native to managed code (long story short, relies on MS extensions to the C++ language that are only available on Windows to work). https://www.mono-project.com/docs/advanced/pinvoke/#runtime-exception-propagation

The other example I could provide is that, when enabled in Cargo.toml, Rust compiles stack trace information into executables such that panic!() correctly prints stack trace info. By default, this information is suppressed unless the RUST_BACKTRACE environment variable is set, but when enabled you can get some pretty detailed diagnostics out from that unwinding of the call stack:

https://doc.rust-lang.org/book/ch09-01-unrecoverable-errors-with-panic.html

[cgranade]

It looks like the screenshot that I shared got dropped when copying my message into this issue, but this is what Rust backtraces look like when enabled: