Windows: Consider alternatives to dbghelp.dll

[ChrisDenton]

The advantage of dbghelp.dll is that it can nearly always be found on any Windows system. However, the major disadvantage is it's ridiculously single threaded:

Note that all DbgHelp functions are single threaded. Therefore, calls from more than one thread to this function will likely result in unexpected behavior or memory corruption. To avoid this, you must synchronize all concurrent calls from more than one thread to this function.

We have to implement synchronization across whatever random dlls may be thrown together and hope to hell nothing else is using it in the same process. It also may be old, The PDB debug format can and does change over time.

A stack backtrace can be retrieved without dbghelp using either CaptureStackBackTrace or RtlVirtualUnwind.

Reading PDB files is more complex but can be done using the Debug Interface Access (DIA) SDK. The downside is this requires an msdia*.dll but at least it's redistributable. The upside is that it has a proper API that doesn't break in the presence of threads.

---

Note: I don't personally have a ton of time atm to follow up on this but I'm posting it here in case someone else wants to. Maybe that someone will be future!me, or maybe not. Also it's fine to conclude that dbghelp is our best option but I'm kinda hoping it isn't.

[ChrisDenton]

As I noted in the experiment linked above, decoupling tracing from symbol loading can be done even without deciding on dia vs. dbghelp. Not needing to load an external dll is great if you just need to store a backtrace for later. Also doing this would mean the windows-gnu targets don't need dbghelp or dia at all since they use DWARF.

If anyone wants to try this then I think the easiest thing would be to try using RtlVirtualUnwind on x86_64 only initially.