<div dir="ltr"><div>Ian, Jon - thanks for your suggestions.</div><div>Kai, please share your vision/opinion.</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 3:16 AM JonY <<a href="mailto:10walls@gmail.com">10walls@gmail.com</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 8/15/20 9:14 PM, Ivan Serdyuk wrote:<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>
> <br>
>> Hi,<br>
>><br>
>><br>
>> On Sat, 15 Aug 2020, Ivan Serdyuk wrote:<br>
>><br>
>>>       Just as Shoaib said, libunwind only is useful in environments<br>
>>>       that use<br>
>>>       the Itanium C++ ABI - there's really no use for it in an MSVC<br>
>>>       context<br>
>>>       (either using MSVC or clang-cl to compile it).<br>
>>><br>
>>>       The particular linker error comes from the fact that there's<br>
>>>       functions<br>
>>>       implemented in assembly, that expect the function name to be<br>
>>>       mangled the<br>
>>>       itanium way, while the object files built by the 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 libunwind and<br>
>>> libbacktrace ?<br>
>><br>
>> Well for libunwind, there's really no use for it in an MSVC setting. All<br>
>> the unwinding functionality is already built into the operating 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>
> <a href="https://docs.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-rtlunwind2" rel="noreferrer" target="_blank">https://docs.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-rtlunwind2</a><br>
> <a href="https://docs.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-rtlunwindex" rel="noreferrer" target="_blank">https://docs.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-rtlunwindex</a><br>
> <a href="https://docs.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-rtlvirtualunwind" rel="noreferrer" target="_blank">https://docs.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-rtlvirtualunwind</a><br>
> ?<br>
> <br>
>><br>
>> For libbacktrace, I guess the _Unwind_Backtrace function in libunwind<br>
>> might work and be useful, even if the rest of libunwind doesn't make sense<br>
>> in such a context.<br>
> <br>
> <br>
> Ian,<br>
> please share your vision/propose some plan.<br>
> <br>
> <br>
>> I haven't tested this function on windows though, and<br>
>> it'd require you to fix the linker error one way or another.<br>
>><br>
> <br>
> I see.<br>
> <br>
>><br>
>> Another alternative, requiring much less code, would be to just extract<br>
>> the SEH version of _Unwind_Backtrace function from libgcc [1]. I think<br>
>> that function is fairly independent from the rest of libgcc and from the<br>
>> rest of the surrounding file, and only calls Windows system APIs.<br>
>><br>
> <br>
> Well, adding committers to the discussion.<br>
> Richard, Tristan, Bernd, Jon - please verify/elaborate.<br>
> <br>
> Thanks in advance.<br>
> Ivan<br>
> <br>
>><br>
>> // Martin<br>
>><br>
>> [1] <a href="https://github.com/gcc-mirror/gcc/blob/master/libgcc/unwind-seh.c#L434" rel="noreferrer" target="_blank">https://github.com/gcc-mirror/gcc/blob/master/libgcc/unwind-seh.c#L434</a><br>
>><br>
>><br>
>><br>
> <br>
<br>
+ Kai Tietz. I have not touched on libgcc unwinders, I believe Kai would<br>
be a better help.<br>
<br>
SEH was only implemented for x86_64 Windows in GCC, Kai described the<br>
32bit implementation was very different. The 32bit SEH was under Borland<br>
patent at the time, but it has since expired.<br>
<br>
</blockquote></div>