Make return address extraction build (and even work) on non-MSVC compilers #845
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
At a minimum, avoid build breaks on non-MSVC compilers.
Turns out that gcc, clang, icc, djgpp, ellcc, and zapcc all define the symbol
__GNUC__and support the gcc return address extraction extensions. So we need only test two symbols:_MSC_VERfor MSVC, and__GNUC__for everyone else.clang and icc implement the gcc extensions for compatibility. djgpp is built on top of gcc, so it inherits the gcc extensions. ellcc and zapcc are built on top of clang, so they inherit the gcc extensions via clang.
For MSVC, you must include
intrin.hbefore using_ReturnAddress(), so we do that explicitly. rather than relying on the kindness of strangers (in this case, relying on apps having theWindowsNumerics.impl.hheader file installed and leaving_XM_NO_INTRINSICS_undefined, so thatdirectxmath.hwill includeintrin.hfor us).I opted against making this a caller-overridable thing, to avoid odr problems. If somebody tries to onboard a new compiler toolchain, the
custom_error_loggertest will fail (null return address), and they can make a PR to this repo to add return address support for it.