<div dir="ltr"><div>Martin,</div><div>good to hear from you.</div><div>Thanks for the effort - I will test on 32bit and 64bit Windows 10.</div><div>I will report ASAP.</div><div><br></div><div>Ivan<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Aug 16, 2020 at 8:42 PM Martin Storsjö <<a href="mailto:martin@martin.st">martin@martin.st</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sat, 15 Aug 2020, Ivan Serdyuk wrote:<br>
<br>
> <br>
> <br>
> On Sat, Aug 15, 2020 at 8:39 PM Martin Storsjö <<a href="mailto:martin@martin.st" target="_blank">martin@martin.st</a>> wrote:<br>
>       Hi,<br>
> <br>
><br>
>       On Sat, 15 Aug 2020, Ivan Serdyuk wrote:<br>
><br>
>       >       Just as Shoaib said, libunwind only is useful in<br>
>       environments<br>
>       >       that use<br>
>       >       the Itanium C++ ABI - there's really no use for it in an<br>
>       MSVC<br>
>       >       context<br>
>       >       (either using MSVC or clang-cl to compile it).<br>
>       ><br>
>       >       The particular linker error comes from the fact that<br>
>       there's<br>
>       >       functions<br>
>       >       implemented in assembly, that expect the function name<br>
>       to be<br>
>       >       mangled the<br>
>       >       itanium way, while the object files built by the<br>
>       compiler expect<br>
>       >       the<br>
>       >       symbols to use the MSVC C++ name mangling, so there's an<br>
>       >       undefined<br>
>       >       reference.<br>
>       ><br>
>       ><br>
>       > I see, thanks.<br>
>       ><br>
>       > Which options exist for MSVC, in sense an alternative to<br>
>       libunwind and<br>
>       > libbacktrace ?<br>
><br>
>       Well for libunwind, there's really no use for it in an MSVC<br>
>       setting. All<br>
>       the unwinding functionality is already built into the operating<br>
>       system,<br>
>       available via the Rtl*Unwind* functions.<br>
> <br>
> <br>
> Martin,<br>
> you mean these functions<br>
> <a href="https://docs.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-rtlunwind" rel="noreferrer" target="_blank">https://docs.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-rtlunwind</a><br>
> <br>
> <a href="https://docs.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-rtlunwind" rel="noreferrer" target="_blank">https://docs.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-rtlunwind</a><br>
> 2<br>
> <a href="https://docs.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-rtlunwind" rel="noreferrer" target="_blank">https://docs.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-rtlunwind</a><br>
> ex<br>
> <a href="https://docs.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-rtlvirtua" rel="noreferrer" target="_blank">https://docs.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-rtlvirtua</a><br>
> lunwind<br>
> ?<br>
<br>
Yes, those are the functions used for unwinding on windows.<br>
<br>
>       For libbacktrace, I guess the _Unwind_Backtrace function in<br>
>       libunwind<br>
>       might work and be useful, even if the rest of libunwind doesn't<br>
>       make sense<br>
>       in such a context.<br>
<br>
Just FWIW, I made a RFC patch that fixes building libunwind in MSVC mode <br>
(still requiring clang-cl though), at <a href="https://reviews.llvm.org/D86041" rel="noreferrer" target="_blank">https://reviews.llvm.org/D86041</a> - <br>
mostly just to show what it takes - not convinced that it necessarily is <br>
something that should be done.<br>
<br>
It does seem like _Unwind_Backtrace in libunwind doesn't work properly on <br>
x86_64 windows at the moment though, but on aarch64 it seems to do what <br>
one would expect.<br>
<br>
// Martin<br>
</blockquote></div>