First of all, a big thanks for putting a lot of effort into this project and for publishing it on GitHub. I have found it very useful for a project I am working on (https://github.com/ekcoh/gtest-memleak-detector), which uses StackWalker in combination with CRTDBG to provide stacktraces for memory-leak detection and automatic trace-messages in automated tests when the software-under-test doesn't clean-up memory correctly.
The problem I have now observed is that x86 builds fails due to MSVC complaining about malformed inline assembly in StackWalker.h lines #227-229. However, if I #undef _M_IX86 (automatically defined) when building for x86 target on my Win10/x64 machine it still works as expected since the RtlCaptureContext approach is selected instead. I have not observed any problems with this. Hence I wonder whether this __asm definition may be outdated somehow or is x86 builds working for others using this library? (Couldn't find any hints regarding x86 not being supported in the README). Any additional information would be helpful, and if this is a bug I wanted to create some awareness around this if someone can give some hints on how to properly fix it.
First of all, a big thanks for putting a lot of effort into this project and for publishing it on GitHub. I have found it very useful for a project I am working on (https://github.com/ekcoh/gtest-memleak-detector), which uses StackWalker in combination with CRTDBG to provide stacktraces for memory-leak detection and automatic trace-messages in automated tests when the software-under-test doesn't clean-up memory correctly.
The problem I have now observed is that x86 builds fails due to MSVC complaining about malformed inline assembly in StackWalker.h lines #227-229. However, if I #undef _M_IX86 (automatically defined) when building for x86 target on my Win10/x64 machine it still works as expected since the RtlCaptureContext approach is selected instead. I have not observed any problems with this. Hence I wonder whether this __asm definition may be outdated somehow or is x86 builds working for others using this library? (Couldn't find any hints regarding x86 not being supported in the README). Any additional information would be helpful, and if this is a bug I wanted to create some awareness around this if someone can give some hints on how to properly fix it.
Additional info can be found in this bug report as well: https://github.com/ekcoh/gtest-memleak-detector/issues/6
My current workaround looks like this:
...but I assume there must be a better way to address this, hence I wanted to reach out here before concluding on this work-around.
There are no problems at all compiling for x64-Debug or x64-Release CMake targets with default settings.